[Fir2_tr] XSD - 3.2

Holcsek Balázs Holcsek.Balazs at educatio.hu
2014. Feb. 14., P, 15:16:48 CET


Kedves Kollégák!

Remélem, hogy megnyugtató válaszokat tudok adni az észrevételekre:

-        Lehetséges, hogy nem volt elég egyértelmű az XSD-hez mellékelt változásnaplóban szereplő leírás a hallgatói és oktatói listalekérdezések lapozásához. Ennek a megvalósítását pontosan úgy tervezzük, ahogy a kért alternatívában szerepel, vagyis a FIR egy kérelemre automatikusan legenerálja az összes válaszüzenetet és mindet beleteszi a csőbe, így ezeket a TR-nek csak végig kell lapoznia a bennük szereplő paging adatok alapján (nem kell aktívan lekérdeznie a további lapokat az első válaszüzenet alapján). Reméljük, hogy így tényleg "lapozhatóságnak" lehet tekinteni ezt a megoldást, nem pedig "lapozandóságnak"

-        A hallgatói és az oktatói adatok lekérdezése esetén a minden egyes személy lekérdezése külön kérelemnek számított eddig is, csak ezeket a külön kérelmeket (legfeljebb 100-at) össze lehetett fogni egy darab tömbösített lekérdező üzenetbe. Ezért a tömbösített lekérdező üzenetben szereplő összes lekérdezéshez külön KerelemID-t is meg kellett adni eddig is. A válaszüzenetben az egyes lekérdezések eredményeiben szerepel a lekérdezéshez megadott KerelemID, így ez kapcsolja össze a kérelmeket a válaszaikkal. Ez a működés továbbra is megmarad, csak míg eddig az egy üzenetben érkező összes lekérdezésre egy üzenetben válaszoltunk, ezután a válaszok több üzenetbe is kerülhetnek, ha együttes méretük meghaladja a 100 megás üzenet-méret-korlátot. A méret alapú darabolás bevezetésének oka az az ellentmondás, hogy az üzenetenkénti fix 100 darabos korláttal sem tudjuk garantálni azt, hogy a válasz ne legyen túl nagy, ha abban szerepelnie kell a hallgatók BLOB mezőinek is (emiatt a fix 100 darabos korlátot csökkenteni kellene) - ellenben ha a válaszban nincs szükség pl. a BLOB mezőkre vagy a lekérdezett személyek összes adatkörére, akkor akár 100 darabnál jóval több válasz is beleférhet egy tömbösített válasz-üzenetbe (vagyis az ilyen lekérdezések nagyon elaprózódnának, főleg ha tovább csökkenne a tömbösíthető lekérdezések száma).

-        A törzsadatok esetén az eddigi XSD kétféle módon is lehetővé tette, hogy egy üzenetben több törzsadat-táblát lehessen lekérdezni egyszerre. Ezek közül az opciók közül a kevésbé optimálisat megszüntettük, a másik viszont továbbra is használható. Mivel a törzsadat-tábláink egyenként nem olyan nagyok, hogy a teljes adattartalmukat tartalmazó üzenet ne férne bele bőven a 100 megás korlátba, ezért itt tábla szinten továbbra sem vezetünk be semmilyen lapozást vagy darabolást. Egy törzsadat-tábla teljes tartalmát továbbra is egy üzenetben fogjuk küldeni, így aki eddig táblánként külön lekérdező üzenettel egyesével kérdezte le ezeket az adatokat, az nem fog lényegi változást tapasztalni. "Válaszüzenet-darabolás" akkor történik, ha egy tömbösített lekérdető üzenetben több törzsadat-táblára is érkezik lekérdezés, és az erre adandó együttes válaszüzenet mérete már meghaladná a korlátot - a darabolás ilyenkor is egész táblánként történik, vagyis az a tábla a teljes adattartalmával együtt új üzenetbe kerül, amelyik már nem férne bele az előző üzenetbe.

-        Ütemezés: terveink szerint február 26-ától kerülnének ki ezek a módosítások a teszt-környezetbe, az éles üzem kezdete pedig március 14 lehetne.

Üdvözlettel,
Holcsek Balázs
Educatio Kft.


From: fir2_tr-bounces at maillist.educatio.hu [mailto:fir2_tr-bounces at maillist.educatio.hu] On Behalf Of Burányi Péter
Sent: Thursday, February 13, 2014 9:50 PM
To: fir2_tr at maillist.educatio.hu
Cc: Rajczi Gábor; Krasznai Dávid
Subject: Re: [Fir2_tr] XSD - 3.2

Kedves Kollégák!

Az új verzióval kapcsolatban az alábbi kérdéseink, észrevételeink vannak.


-        Jól értjük-e, hogy a hallgatói és oktatói lista lekérdezések esetében a válaszok első elemében megkapjuk a teljes válasz méretét (tételszámát) és ennek megfelelően kell folytatni az adatlekérdezést (egymás után láncolva a kérdéseket az azokra kapott válaszok alapján) addig, amíg a lista összes tételét vissza nem kaptuk? Az a félelmünk, hogy ez a működési mechanizmus nagymértékben fogja lassítani az adatfogadást. Az alternatívát ebben látjuk: egy darab lista kérelemre automatikusan megkapjuk az összes üzenetet (a FIR a központi oldalon legenerálja az összes válasz üzenet darabot és bele is tölti a csőbe) és feldolgozás során ezeket kell végiglapozni a válaszüzenet paging adatai alapján. De még jobban örülnénk a jelenlegi működésnek :)

Azt is csinálhatjuk persze, hogy az első válasz alapján legeneráljuk egyben az összes szükséges kérdést, de ez nem változtat azon, hogy egy nagyobb válaszcsomag összes darabjának kiolvasásához rengeteg kérelmet kell generálni és a választ (meglehetősen kis) darabokban feldolgozni - feltéve persze, hogy mindent jól értünk.

-        Azt írjátok, hogy a hallgatói és oktatói adatok lekérdezése esetén egy tömbösített lekérdező üzenetben akár 100-nál több hallgató illetve oktató adatainak elkérésére is lehetőség lesz. A válaszüzenetek darabolása azt jelenti-e, hogy több válasz csomagban ugyanaz a KerelemId szerepel, de egy adott válasz üzenet továbbra is csak 100 tételt tartalmaz? Ha igen, mi fogja vezérelni a válaszok feldolgozását? Ebben a válasz típusban nem látjuk a lista válaszoknál alkalmazott lapozó (paging) attribútumokat. Honnan fogjuk tudni, hogy mikor érkezett meg a feltett kérdésre vonatkozó összes válaszüzenet (-darab)? Egyszerűen csak várjuk meg, amíg a csőből minden kérdezett személyre valamelyik üzenetben megérkezik a válasz?

-        Törzsadatok esetében hasonló kérdésünk van: mit jelent a "darabolás"? Ha jól látjuk az xsd-ből, itt is bekerül egy 100 rekordos korlát - ez feltétlenül szükséges? Őszintén szólva, mi eddig jól elvoltunk azzal, hogy nem egyben, hanem típusonként kérdeztük le a törzsadatokat, így nem nőttek a válaszok kezelhetetlenül nagyra, viszont egyszerű volt a lekérdezés és a feldolgozás automatizálása. Jól értjük, hogy most százasával jönnek a válaszok minden típusra, és egyszer csak elfogynak az adott típusból a feldolgozandó üzenetek? Mivel itt sem látjuk a lapozásra vonatkozó attribútumokat, javasoljuk azok bevezetését (a válaszban - kérdezni nem szeretnénk ez alapján!) vagy az utolsó csomagdarab megjelölését (hogy tudjuk, ha már az adott típusból elfogytak a feldolgozandó üzenetek).

-        A bevezetési folyamatra vonatkozó kérdésünk: mikor lesz elérhető a tesztrendszeren az új verzió?

-        A bevezetési folyamatra vonatkozó észrevételünk: a március eleji éles bevezetést kicsit korainak tartjuk (bár ez a véleményünk a fenti kérdésekre adott válaszok és a tesztelési tapasztalatok függvényében változhat). A 3.2 verzió lapozhatóságra (amit talán inkább "lapozandóságnak" lenne helyes nevezni) vonatkozó megszorításait kicsit visszalépésként éljük meg, különösen a lista lekérdezések és törzsadat lekérdezések területén. A hallgatói és oktatói adatok területén azért nem, mert ezeket éppen a lista lekérdezések vezérlik: a lista válaszokból pontosan látjuk, hogy kikre kell adatot lekérdeznünk, ezt a halmazt kvázi tetszőlegesen tudjuk darabolni már a kérdés oldalon és ellenőrizni tudjuk azt is, hogy az összes válasz megérkezett-e. Az előbbi két esetben ugyanakkor nincs semmilyen kiinduló információ, és - ha jól értjük a folyamatokat, akkor - a válaszfogadás kicsit elbonyolódik. Ezeknél az adatköröknél ráadásul nem látjuk a kényszert sem a válaszcsomagok darabolására, bár ez nyilván a ti oldalatokon látszik jobban. Ha valamit nagyon rosszul értünk a folyamatban, akkor elnézését, és kérlek, térítsetek észre bennünket.

Üdv

Burányi Péter
DEXTER Kft.


From: fir2_tr-bounces at maillist.educatio.hu<mailto:fir2_tr-bounces at maillist.educatio.hu> [mailto:fir2_tr-bounces at maillist.educatio.hu] On Behalf Of Köblös István
Sent: Tuesday, February 11, 2014 9:02 AM
To: fir2_tr at maillist.educatio.hu<mailto:fir2_tr at maillist.educatio.hu>
Subject: [Fir2_tr] XSD - 3.2

Sziasztok!

Mellékelem az XSD 3.2 tervét. Kérlek Titeket, hogy a héten jelezzetek vissza, ha valami nem megfelelő benne, módosítási kérésetek vagy javaslatotok lenne.

Várhatóan március elején élesítenénk, pontos ütemezést holnap tudok küldeni.

Üdv,
István

Jelen elektronikus levélre vonatkozik az Educatio NKft. Adatvédelmi tájékoztatója.<http://educatio.hu/cegunkrol/adatvedelmi_tajekoztato>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://polar.educatio.hu/pipermail/fir2_tr/attachments/20140214/97f6b4ba/attachment-0001.htm 


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