Open hlageek opened 2 years ago
Doplňuji, že u mne se rovnou obohacení tvářilo jako neúspěšné (uuid:61149f70-bd7e-4ebe-be45-146258e8b8c5). Systém však neříká proč se to nepodařilo, což je značně nepraktické.
Dobrý deň,
ďakujeme za spätnú väzbu.
Prvá chyba vznikla z dôvodu, že druhý ročník danej publikácie (ročník 1873) obsahuje ako podradené objekty aj výtisky (objekty typu PeriodicalItem) aj stránky (objekty typu Page). Kramerius+ počítá s tým, že Periodiká obsahujú ako podradené objekty ročníky (PeriodicalVolume), tie obsahujú ako podradené objekty výtisky (PeriodicalItem), a až tie obsahujú stránky.
Toto značne komplikuje situáciu, pretože to vyzerá, že sa nemôžeme spoľahnút na žiadnu pevnú hierarchickú štruktúru objektov. Máme dve možnosti, ako sa s tým vysporiadať:
Objem publikácie pravdepodobne zhodil server, preto všetky nasledujúce požiadavky o obohatenie neprechádzajú.
Prosím teda o vyjadrenie, ktorú možnosť máme implementovať.
Osobně jsem jednoznačně pro variantu 2, protože varianta 1 by z pohledu uživatele velice problematická - nikdy by nevěděl, zda pracuje opravdu s kompletní publikací. Pokud by to bylo z pohledu knihoven (@zabak, @JanMeritus, @MLhotak) realizovatelné, jde uvažovat i o střední cestě, kdy by se tyto chyby logovaly a obohacení se neprovedlo. Admin by pak následně mohl provést opravy ve struktuře. Vůbec ale netuším, nakolik se jedná opravdu o "chybu" ve struktuře publikace, nebo zda jde o žádoucí stav.
Díky @bodnarIQ za zjištění, kde je problém. Mám štěstí na problematické volby, což je pro testování ideální kvalifikace :-D Souhlasím s @motyc, že by se na to v první řadě měli podívat knihovníci. Je to chyba na straně knihoven? Nebo je z jejich pohledu absence jednotné struktury to správné řešení. Než zjistíme, jak to vnímají knihovny, já bych aspoň prozatím přidal dvě možnosti:
Já bych se skoro přikláněl k možnosti 4., protože v případě volby 1. uživatele ochuzujeme o nějakou (možná ani ne zanedbatelnou část dat), a v případě možnosti 2. problém se strukturou přehazujeme, byť za cenu náročného technického řešení, na uživatele, který si také nebude vědět moc rady s tím, co teda kam patří a jaký je mezi typy objektů vztah. Myslím, že vynucení konzistence je nakonec nejvýhodnější postup pro všechny. Sice se sem tam Kramerius+ odchýlí od Krameria, ale aspoň budeme vždy vědět jak.
Před chvílí jsem zkoušel obohatit dokument s uuid:57f3ff20-9ee3-11e3-8b69-005056825209
. Proces skončil chybou:
UUID: uuid:57f3ff20-9ee3-11e3-8b69-005056825209
Status: FAILED
Vytvoření: 25. 1. 2022 15:07:21
Chyba: Object with UUID=uuid:57f3ff20-9ee3-11e3-8b69-005056825209 not found
V MZK dokument existuje: https://dnnt.mzk.cz/view/uuid:57f3ff20-9ee3-11e3-8b69-005056825209
Dneska (1. 2. 2022) jsem publikaci zkoušel obohatit pomocí volání API (... configUrl=/v3/api-docs/swagger-config#/filler-api/enrichPublication). Opět bezúspěšně. Takto vypadaly odpovědi ze serveru:
500 Undocumented
{
"timestamp": "2022-02-01T09:47:13.217+01:00",
"status": 500,
"error": "Internal Server Error",
"message": "",
"path": "/api/filler/uuid:57f3ff20-9ee3-11e3-8b69-005056825209"
}
200 OK
Varianta 2 je v podstatě jediná možná. V Krameriu 7 je přidán druh dokumentu virtuální sbírka, který může obsahovat naprosto cokoli, včetně dalších virtuálních sbírek. U toho periodika to je správně, protože ty stránky obsahují jednak vazbu toho ročníku (to se pravda většinou neskenuje) ale hlavně obsah daného ročníku (a to bývá častější).
Zároveň prosím otestujte i konvoluty - zatím máme 3 kusy, je to poměrně nový druh dokumentu, kombinující jiné dokumenty různých druhů do jednoho svazku (dokument s přívazky) https://www.digitalniknihovna.cz/mzk/search?doctypes=oldprintomnibusvolume
Testoval jsem nejnovější verzi z pondělka. Kniha s uuid:08ec2340-38ca-11e4-8e0d-005056827e51
o 464 stranách. Objevila se chyba Prematurely reached end of stream.
UUID: uuid:08ec2340-38ca-11e4-8e0d-005056827e51
Status: FAILED
Vytvoření: 2. 3. 2022 10:07:27
Zpracovávání: 464/464
Stav: 100.0%
Chyba: Prematurely reached end of stream; nested exception is com.mongodb.MongoSocketReadException: Prematurely reached end of stream
Následně jsem ještě obohatil publikaci s uuid:ed788ee0-4d24-11e4-8113-005056827e52
(64 stran). Obohacení proběhlo.
Obě publikace se objevily v seznamu obohacených publikací. Když jsem je dal exportovat (formát TEI bez žádných nastavených parametrů), objevila se zpráva o probíhajícím exportu, ale ani jedna publikace se v seznamu Vygenerovaných exportů neobjevila.
Export do formátu JSON (bez žádných nastavených parametrů) proběhl v pořádku a kniha se objevila v seznamu Vygenerovaných exportů.
Export do formátu TEI s nastavenými parametry proběhl v pořádku a kniha se objevila v seznamu Vygenerovaných exportů.
Opět chyba při obohacování u další publikace (748 stran).
UUID: uuid:b5251ae0-2457-11e4-8e0d-005056827e51
Status: FAILED
Vytvoření: 3. 3. 2022 7:20:28
Zpracovávání: 748/748
Stav: 100.0%
Chyba: Prematurely reached end of stream; nested exception is com.mongodb.MongoSocketReadException: Prematurely reached end of stream
Po exportu publikace s uuid:b5251ae0-2457-11e4-8e0d-005056827e51
se objevila chyba 503 Service Unavailable. The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Šlo o export s id c2d04212-0089-401d-80b8-03ea1b8e0a8a
. Viz https://dl4dh.inqool.cz/api/export/download/05a6af9c-dea1-48b3-9052-afff1671af44.
Nyní na uvedeném uuid uuid:440337bd-5625-11e1-9505-005056a60003
fungují 3 ze 4 úloh, ale úloha DOWNLOAD_K_STRUCTURE
stále failuje.
Problém je v tom, že publikace s uvedeným UUID je k dispozici v knihovně MZK a KNAV, nikoli NK, na kterou je nyní napojené prostředí DEV i TEST.
Když si člověk klikne na řádek s chybou (FAILED
), zobrazí se podřízený formulář Vykonané kroky v zvolenom běhu
, tady je možné opět kliknout na řádek s chybou, až se objeví přesná příčina selhání. V tomto případě šlo o 404 Not Found from GET https://www.ndk.cz/search/api/v5.0/item/uuid:440337bd-5625-11e1-9505-005056a60003
.
Díky za vysvětlení @daliboris - takže tento konkrétní záznam testovat nelze. Ale spíš mě tedy straší, že ostatní úlohy se hlásí jako COMPLETED
.
Stažení publikace z Krameria proběhla úspěšně 6. a 9. 5., kdy bylo Kramerius+ nejspíš napojený na MZK. Úlohy obohacení, které proběhly při dnešním spuštění úspěšně, využívaly metadata a data (ALTO, které se ukládá do K+ právě pro tyto případy) z těchto prvních stažení.
Jde tedy o to, jestli má být úspěšné stažení dat z Krameria (DownloadPublicationStep
) podmínkou pro spuštění dalších úloh v konfiguraci. Pokud se tento krok nepovede, měly by se ty následující úlohy považovat za neproveditelné? (Nějaký další příznak, např. SKIPPED
?)
Asi tedy tam, kde nebudou data v K+, by i dalsi ulohy selhaly (doufam) jako FAILED
. Tak je otázka, zda v tomto issue jde teď už jen o artefakt našeho testování, nebo zda takové situace, kdy se daří obohatit, ale ne stáhnout, můžou vytvořit problém i na produkci.
Problém při pokusu obohatit uuid:440337bd-5625-11e1-9505-005056a60003