[Fir2_tr] XSD - 3.2

Burányi Péter Buranyi.Peter at dexter.hu
2014. Feb. 13., Cs, 21:50:08 CET


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
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://polar.educatio.hu/pipermail/fir2_tr/attachments/20140213/a193c877/attachment.htm 


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