Closed jkremlacek closed 7 years ago
Dotaz se podařilo vyhodnotit rychleji díky optimalizaci dotazu. Bylo nalezeno 945 takto poškozených záznamů - viz googledoc, druhá záložka.
Chybová hláška při pokusu o (re)import vadného foxml do krameria: sterr.txt
Projevuje se i při importu do čisté fedory.
Hmm, teď se na to víc dívám a asi bych to ještě potřebovala dovysvětlit. 403 to vrací, protože záznam není v DoRegistry a DoFields? Nebo to s tím nesouvisí? A víme, proč to tam není? Dívám se do Krameria na jeden z těch dokumentů s internal part a jako takto tam nevidím nějaký problém. Chová se to stejně jako články u periodik.
Primární podmínkou téhle chyby je, že pro dané uuid není záznam v doFields (df) a doRegistry (dr). Spolu s tímhle je ale zatím neznámý problém i ve foxml souboru - u funkčního objektu zkusil @Jenyk smazat df a dr a i tak fungoval a stejně tak vytažené foxml by mělo jít importovat čistého Krameria a to taky nejde viz. komentář @xburda4
Foxml (nezávisle na funkčnosti jejich záznamu) vytažené z fedory krameria nejdou použít na importování do krameria. Kramerius resp. jeho fedora v takovém případě vyhodí chybu .
Znovuzavedení problémových souboru tedy tímhle způsobem nepůjde a je potřeba najít jinou cestu.
V tom stacktrace je tento zajímavý řádek
org.fcrepo.server.errors.ObjectIntegrityException: FOXML IO stream was bad : Malformed URL: uuid:9dde3310-3c3f-11e6-8746-005056825209+TEXT_OCR+TEXT_OCR.0
Zdvojený suffix TEXT_OCR jsem ještě nikdy neviděl.
To url je v pořádku, ale odkazuje na datastream, který zřejmě v té fedoře není. O tom jsem psal na gitteru - datastreamy jsou ve fedoře jinde než foxml a k5 to při exportu spojuje. Zkus ten odkaz na OCR smazat a importovat to znova.
Po smazaní datastreamu OCR a ALTO (oba s odkazem do fedory, typu "+x+x.0") import proběhl.
Zkusím debugovat import foxml co použil @xburda4 na čem to vázne.
Tam to byla kombinace 1x monograph, 1x internalpart a 1x page. Takže to bude asi ten samý problém u té stránky :)
U stránky má OCR a ALTO u sebe element binaryContent, takže tam by měl být problém jinde. Projistotu jsem je u stránky zkusil smazat a chyba se nezměnila.
Fedora vyhazuje RDFParseException s chybou "unqualified property element
Jedná se o elementy:
<pageFrom>id_0011r</pageFrom>
<pageTo>id_0045v</pageTo>
Podobný údaj se vyskytuje i v mods:
<mods:extent unit="pages">
<mods:start>11r</mods:start>
<mods:end>45v</mods:end>
<mods:total>503</mods:total>
<mods:list>s. 11r - 45v</mods:list>
</mods:extent>
<mods:detail type="pageNumber">
<mods:number>11r</mods:number>
</mods:detail>
Po smazání elementů pageFrom a pageTo import projde, selže až batch_state. Konkrétně selhává "Indexace dokumentu: a24d4a70-d07a-11e5-ab98-005056827e52" s poznámkou Reindexace. Log chyby
Edit: do čistého Krameria chyba s batch importem nenastává (nejspíš předchozí pokusy o import nechaly ve fedoře nějaké artefakty)
Reimport do hlavního krameria prošel, chyba je vyřešena.
Nastal ovšem další problém, že odkazy na obrázky vedou na doménu klokan.mzk.cz/... , která je dávno nefunkční a tím pádem není ani jisté jestli bude mít smysl reimportovat tyto záznamy do krameria, pokud by měly obsahovat pouze thumbnail.
Pokusíme se skeny najít a v případě úspěchu proběhne reimport poškozených monografií.
Edit: Podle čárového kódu jsou skeny dohledatelné.
Budou se tedy postupně opravovat záznamy podle google sheet dokumentu.
U stránek odkazujících na .jpg na doméně klokan.mzk.cz bylo zapotřebí doplnit elementy kramerius:file
a kramerius4:tiles-url
, aby fungovala prohlížečka v UI krameria.
Rozbité dokumenty jsou funkční.
Záznamy v repozitáři, které mají záznam v databázi ObjectPath a ne v DoRegistry a DoFields v hodně případech vyhazují chybu.
Částečný seznam poškozených souborů je dostupný na: googleDocs
Kompletní seznam je potřeba získat z DB (dlouhé vyhodnocení dotazu), bude spuštěn, v případě problémů se bude muset hledat alternativa.