Názory k článku e-Sbírka ukazuje, jak neotevírat data

Mysleli jsme to dobře, ale dopadlo to jako vždycky.

normálně bys ten soubor četl "po řádku", tj. kousek načetl do paměti, zpracoval a z paměti vyhodil, takhle bys postupně prolezl celý soubor. použitý formát a jeho struktura ale tohle neumožňuje a většina nástrojů na jeho zpracování si s tím neumí poradit, takže musí načíst do paměti celý datový soubor a s ním pak pracovat.

Proudová struktura funguje tak, že můžete data číst třeba ze sítě a rovnou je zpracovávat. Tj. nemusíte mít ten soubor vůbec uložený na disku a můžete tak zpracovat větší soubor, než kolik máte RAM nebo prostoru na disku. Teoreticky ten vstup může být i nekonečný.

U JSONu se předpokládá, že nejprve z celého JSONu vyrobíte objekt, který následně budete zpracovávat. (Např. proto, že nemá definované pořadí prvků.) Proto se pro zpracování streamovaných dat používá třeba JSON lines, kde jde jeden „malý“ JSON na jednom řádku (z toho uděláte objekt) – ale celý ten stream není pole v JSONu, u kterého byste při obvyklém zpracování čekal teprve až se dostanete na konec pole, a teprve pak byste mohl zpracovat jeho obsah.

JSON se samozřejmě dá zpracovat i streamově, můžete zpracovávat jeden prvek pole za druhým a nečekat, až dostanete celé pole. Ale vyžaduje to splnění některých předpokladů, které obvykle nebývají explicitně zaručené. A protože to není zamýšlený způsob použití JSONu, ne každá knihovna to podporuje.

Jako příklad si představte to, že v jednom místě objektu můžete mít několik různých typů (klasický polymorfismus z objektového programování). Když ta data chcete zpracovávat streamově, musíte mít zaručeno, že se nejprve dozvíte typ, a teprve pak budou samotná data pro daný typ. Jenže pokud vám to někdo pošle v JSONu takhle, streamově to nezpracujete:

{
  "polozky": […hrozně dlouhé pole, které by bylo dobré zpracovat streamově…],
  "typ": "A",
}

JSON nemá prostředky, jak tohle zaručit, takže maximálně byste mohl mít někde v dokumentaci slovně popsáno, že v serializovaném JSONu bude v tomto místě vždy uveden nejprve typ a až potom položky.

"Samotné uzavření systému je ale další z naprosto zbytečných překážek."

...

https://isir.justice.cz/isir/common/stat.do?kodStranky=PROVOZPODMINKY

"Ministerstvo spravedlnosti vyhrazuje právo omezit či zakázat přístup k databázi insolvenčního rejstříku uživateli, který denně odešle k vyřízení více než 3000 požadavků"

Jup... a kdo ma zajem otestujte, nize uvedene, aby sranda fungovala, potrebujete mit fungujici IPv6.

wget https://isir.justice.cz:8443/isir_cuzk_ws/IsirWsCuzkService?wsdl

Tohle bude nepochybne presne totez, a proto tam ani verejny pristup povolit nechteji. Ostatne delalo to Asseco, takze to mozna 10 uzivatelu zaroven zvladne ... horkotezko.

Pokud cílem projektu bylo proprat nějaký ty kačky, tak je to myslím úspěšný projekt. Co se vám pořád nelíbí?

Místo formátu, který by umožňoval proudové zpracování, dodavatel zvolil strukturu, která vybízí k načtení celého souboru do paměti (a málokterá implementace dovolí tuto strukturu zpracovávat postupně), což u souboru, který má 27 gigabajtů, jde na běžném hardwaru velmi těžko.

Můžete mi prosím ještě, jako neznalému problému ideálně na jednoduchém příkladu, popsat v čem je ten jejich formát špatně a jak by to mělo být správně?

To píšou už v článku, ale pořád to neříká, v čem je přesně problém, jak se liší proudová vs. použitá struktura. Jinak by podle mě šlo namapovat soubor do adresního prostoru (mmap) a tam s ním pracovat, ale to asi neumí všechny nástroje.

Kdyby to někomu pomohlo, tak jednoduché JSON API je dostupné například zde
https://opendata.eselpoint.cz/esel-esb/eli/cz/sb/1998/156