[Fir2_tr] Lastupdate alapú törzsadat lekérdezések válaszai

KODACSY Tamas kodacsy.tamas at kodasoft.hu
2020. Aug. 19., Sze, 19:12:41 CEST


Szia Imi,

a törzsadatoknál a lastupdate funkció javítása nagyon jó! Az SZNY-ben is 
alkalmazzuk ezt, természetesen nem az ETN rendszeridejéhez viszonyítva, 
hanem a korábban FIR-ből visszakapott lastupdate-re vonatkozóan. 
Kezdettől fogva hasznos funkció a FIR-ben, ami jelentősen gyorsítja a 
rendszerek közötti szinkronizálást.
Ehhez persze rendkívül fontos, hogy a triggerek pontosan kövessék a 
FIR-es adatbázis változásokat, és a törlést is nyomon tudjuk követni.

Most kérdeztem le egy lastupdate-s szótárkészletet élesben az alábbiak 
szerint:
<fir2:TorzsadatLekerdezesek>
         <fir2:TorzsadatLekerdezes KerelemID="6202007020000110">
             <torzs:LastUpdate>
                 <torzs:KesobbMint 
akkor="false">1970-01-01T00:00:00+01:00</torzs:KesobbMint>
             </torzs:LastUpdate>
<torzs:TorzsadatTipus>SzotarElem</torzs:TorzsadatTipus>
         </fir2:TorzsadatLekerdezes>
     </fir2:TorzsadatLekerdezesek>

A válaszban két súlyos problémát látok:

1) Nem mindig valóságos adatokat kapunk vissza a LastUpdate mezőben, pl. 
ez az azonosítóval egy üres snapshot:
<ns6:SzotarElem Tipus="OKMTIP" Kod="DIG" 
LastUpdate="2019-07-29T12:42:51.928+02:00"/>
Viszont az OKMTIP/DIG adatok nem 2019-07-29-én törlődtek, hanem sokkal 
később. 2019 decemberében is küldtünk diákig adatokat! Hasonló problémák 
állnak fönn más szótárelemeknél is (OKMTIP/SIG, UTL, VEZ, stb).
Ez azt jelenti, hogy a LastUpdate megbízhatatlan és ellentmondásos, ezt 
kérem szépen javítani.

2) Ha teljes szótártípust töröltök, akkor semmit nem kapunk vissza, így 
a LastUpdate lekérdezésekkel nem tudjuk követni a törlést. Pl. a 
lekérdezésben nincs a "HLGJVTIP", ami korábban szótártípus volt, 
adatokat jelentettünk be ezzel. Egy lastupdate-s lekérdezés nem tud 
választ adni arra, hogy a HJVLTIP egy adott időponthoz képest csak nem 
változott és ezért hiányzik, vagy végleg eltűnt a készletből.
Ez viszont struktúrális probléma, ami lehetetlenné teszi a LastUpdate-re 
való hagyatkozást, és továbbra is a teljes adatlekérdezésre szorít minket.

Összességében elfogadhatatlannak tartom, hogy a FIR3 szakított a 
historikusság elvével, aminek egyik következménye az, hogy a LastUpdate 
alapú törzsadat-lekérdezés logikailag használhatatlan (még akkor is, ha 
a hibás időpontok javításra kerülnek). Az ezzel kapcsolatos 
észrevételeimet újra csatolom, hozzátéve a LastUpdate 
törzsadatlekérdezés problémáját is.

Kérlek, fontoljátok meg ennek a beláthatatlan informatikai következményeit.

Üdv,
Koda


On 2020. 08. 18. 12:54, Pató Imre wrote:
>
> Sziasztok!
>
> A FIR *lastupdate alapú törzsadat lekérdezés*einek módosulásáról és a 
> törzsadatok inkrementális szinkronizálásának lehetőségéről szeretnék 
> néhány fontos információt adni.
>
> A FIR adatait tároló adatbázis-táblákban a lastupdate-eket triggerek 
> töltik - ha bármi módosul egy sorban, akkor a lastupdate értéke is 
> automatikusan változik. A lastupdate ezért egy technikai információ, 
> nem pedig hatályossági információ - csak azt naplózza, hogy az adott 
> rekordhoz mikor nyúltunk hozzá utoljára (pl. adatjavítási célból).
> A FIR adatbázisaiban a korábban már kiosztott azonosítók 
> fenntartásának érdekében fizikai adatrekord-törlést üzemszerűen nem 
> végzünk. A logikai törlés során a rekordok lastupdate-je szintén 
> módosításra kerül.
>
> A logikailag törölt rekordok a törzsadat lekérdezésekkor nem jelennek 
> meg a FIR által adott válasz-üzenetekben. A törzsadat lekérdezések 
> *lastupdate alapú szűrései* viszont arra szolgálnak, hogy a 
> segítségükkel inkrementális adatszinkronizáció legyen megvalósítható, 
> ahhoz pedig fontos, hogy a lekérdezés válaszába a törlendő adatokról 
> is kerüljön információ. A FIR2-ben ez a törzsadatok esetén sajnos nem 
> működött jól, ezért a FIR2 lastupdate alapú lekérdezései nem voltak 
> alkalmasak a törzsadatok inkrementális szinkronizálására. A FIR3-ban a 
> lastupdate alapú szűrések esetén a válaszok összeállítása úgy 
> történik, hogy ha a lekérdezett adatkörben a lekérdezési feltételnek 
> megfelelő időszakban egy adott azonosítóhoz tartozó bármelyik rekord 
> (egy azonosítóhoz tartozhat több rekord is különböző hatályossági 
> adatokkal, illetve összetett adatkör esetén a kapcsolódó táblákban is 
> tartozhatnak hozzá további rekordok) megváltozik (ideértve a rekord 
> logikai törlésést is), akkor a válaszba bekerül egy teljes aktuális 
> snapshot az adott azonosítóhoz tárolt adatokról. Tulajdonképpen az 
> történik, hogy az adott azonosítóhoz tartozó snapshot lastupdate-jének 
> kiszámításakor figyelembe vesszük az azonosítóhoz kapcsolódó törölt 
> rekordokat is, a válaszba kerülő snapshot azonban csak a hozzá tartozó 
> élő rekordokat tartalmazza. Ennek megfelelően, ha egy azonosítóhoz 
> tartozó összes adatot (vagyis magát az azonosítót) töröljük a FIR-ben, 
> akkor a megfelelő lastupdate alapú lekérdezés válaszába az adott 
> azonosítóval egy üres snapshot kerül. *A normál törzsadat lekérdezések 
> válaszaiba ezek ez üres (törölt) snapshot-ok nem kerülnek be.*
>
> Egy inkrementális szinkronizáció megvalósításához fontos kérdés, hogy 
> milyen feltételekkel kell futtatni a változásokat visszaadó lastupdate 
> alapú lekérdezéseket. Ehhez több okból sem megfelelő a korábbi 
> szinkronizálás időpontjához képest történt változások lekérdezése. A 
> FIR és a lekérdező rendszer óráinak esetleges kisebb eltéréséből eredő 
> problémák mellett fontosabb adottság, hogy a FIR az adatok 
> feldolgozását és a feldolgozott adatok publikálását külön lépésekben 
> végzi. Az adatbázis rekordjainak módosítása a feldolgozás során 
> történik, így a módoított rekordok lastupdate-jei is a feldolgozás 
> során állítódnak be, viszont ezek a módosulások az adatlekérdezésben 
> csak a publikálás után látszódnak. Emiatt egy feldolgozás közbeni 
> szinkronizáció esetén a feldolgozásban a szinkronizáció előtt, de a 
> korábbi publikálás óta történt módosulások nem látszódnak. Ezek a 
> következő szinkronizációba is csak akkor kerülnek be, ha a lastupdate 
> alapú lekérdezés szűrő feltételébe nem az előző szinkronizálás 
> időpontja, hanem az adott adatkör egészében történt utolsó ismert 
> módosulás időpontja kerül. Ez az érték számítható a TR-ben tárolt 
> adatok alapján (max lastupdate a megfelelő adatok között) is, de 
> használható a FIR által a lekérdezés válaszában az utolsó 
> lekérdezéskor az adatkörre vonatkozóan visszadott érték is.
>
> Ha ennek kapcsán kérdésetek vagy problémátok merül fel, kérdezzetek 
> nyugodtan.
>
> Üdv:
>
> Imi
>

--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lista.sulinet.hu/pipermail/fir2_tr/attachments/20200819/4ea5971c/attachment-0001.html>
--------- következő rész ---------
A non-text attachment was scrubbed...
Name: FIR historikussag elve.pdf
Type: application/pdf
Size: 435575 bytes
Desc: nem elérhető
URL: <http://lista.sulinet.hu/pipermail/fir2_tr/attachments/20200819/4ea5971c/attachment-0001.pdf>


További információk a(z) Fir2_tr levelezőlistáról