Problém s mazáním chybných dat

[svetlym]

Dobrý den,

nedaří se nám z K7 odmazat chybně se zobrazující tituly:

https://www.digitalniknihovna.cz/mlp/view/uuid:b8ef1360-840d-11dd-83c6-000d606f5dc6 https://www.digitalniknihovna.cz/mlp/view/uuid:B8EF1360-840D-11DD-83C6-000D606F5DC6

Problém nejspíš vznikl tak, že Sirius, ve kterém jsme vyráběli data pro K3, generoval UUID v uppercasu, nejspíš to v K3 nebylo case sensitive. Při pozdějších úpravách vznikl ten samej titul s tím samým uuid, ale v lowercase, a díky case sensitivitě se při reimportu v K4 nepřepsal, ale zduplikoval.

V K7 se nám ani jedna verze nezobrazuje. Pokus je odmazat, abychom mohli naimportovat správnou verzi, hodí následující chybu:

Mar 19, 2024 3:29:35 PM cz.kramerius.adapters.impl.krameriusNewApi.ProcessingIndexImplByKrameriusNewApis fetchStructure
SEVERE: found multiple own parent relations: uuid:b8ef1360-840d-11dd-83c6-000d606f5dc6 -hasPage-> uuid:5a0128d0-436b-11dd-849b-000d606f5dc6 and uuid:B8EF1360-840D-11DD-83C6-000D606F5DC6 -hasPage-> uuid:5a0128d0-436b-11dd-849b-000d606f5dc6
cz.incad.kramerius.fedora.om.RepositoryException: found multiple own parent relations: uuid:b8ef1360-840d-11dd-83c6-000d606f5dc6 -hasPage-> uuid:5a0128d0-436b-11dd-849b-000d606f5dc6 and uuid:B8EF1360-840D-11DD-83C6-000D606F5DC6 -hasPage-> uuid:5a0128d0-436b-11dd-849b-000d606f5dc6
at cz.incad.kramerius.repository.KrameriusRepositoryApiImpl.getParents(KrameriusRepositoryApiImpl.java:206)

Existuje způsob, jak tyhle tituly z K7 korektně smazat? Předpokládám, že když dám Smazat objekty (nízkoúrovňově), smažou se jen kořenový objekty a zbytek stromu zůstane viset v úložišti?

[vlahoda]

Na stranku uuid:5a0128d0-436b-11dd-849b-000d606f5dc6 odkazuji dva nadrazene objekty - uuid:b8ef1360-840d-11dd-83c6-000d606f5dc6 a uuid:B8EF1360-840D-11DD-83C6-000D606F5DC6. V K5 to nevadilo, novy indexer v K7 to ale neumoznuje a bohuzel kvuli tomu zatim neni ani mozne takovy zdvojeny strom smazat. To blokovani mazani casem opravime. Nizkourovnove smazani toho objektu uuid:B8EF1360-840D-11DD-83C6-000D606F5DC6 by tento konkretni problem vyresit mohlo, ale muze zpusobit dalsi nekonzistence - netusim, jak tam jsou dalsi vazby.

[rzeh4n]

Z javadocu:

/**
     * Low level deletion from Repository and Search index.
     * Relations pointing to this object from another objects will be NOT automatically removed.
     * I.e. this operation can cause incorrect state of data in Repository (according to Kramerius) and Search index.
     * <p>
     * For example:
     * <p>
     * before deletion:
     * Periodical1 --hasVolume--> Volume1 --hasItem--> Issue1 --hasPage--> Page1
     * <p>
     * after deletion of issue1:
     * - Issue1 will be removed from Akubra (FOXML, managed datastreams)
     * - Issue1 will be removed from Processing index
     * - relations to and from Issue1 will be removed from Processing index
     * - Volume1 will still reference Issue1 in it's FOXML (with hasItem)
     * - Page1 will have incorrect data in Search Index (pid paths etc). But after reindexation this will be corrected will lose any connection to Periodical1, Volume1, Issue!1.
     *
     * @param pid
     * @return
     */

Takže v tomhle případě:

• smazání uuid:B8EF1360-840D-11DD-83C6-000D606F5DC6 smaže objekt samotný, ale i odkazy v Processing index z/na něho
• jestli už na mazaný objekt nic neodkazuje z vrchu (hasItem, ...), tak by tohle mělo stačit
• pokud na to něco (objekt X) odkazuje, zůstane nekonzistence mezi FOXML objktu X a processing indexem (tam už vazba z X není). Potom stačí na souborovém systému upravit foxml objektu X a vazbu smazat.

Obecně při nekonzistenci mezi Processing indexem a Foxml by se to mělo vyřešit přes proces "Rebuild processing index pro konkrétní objekt". Ten synchronizuje vazby z objektu ve FOXML a Processing indexu.