Project

General

Profile

Bug #2071

Håndtering af pid ved skift af opensearch

Added by Steen Larsen about 3 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Estimated time:
URL med eksempel:
Kategorier:
Søgning - Værkvisning, Min konto - Huskeliste og Gemte søgninger, Inspiration - Karruseller, Søgning - Søgeresultat efter søg - Brønd

Description

Det er et forsøg på en opsummering/fortsættelse af #1698

Når man skifter opensearch version - f.eks. mellem 4.0.1 - 3.0_4.2 - 3.5 skifter biblioteksposterne pid (pid = namespace:faust).
Skiftet kan være af namespace og/eller faust.

Det er uheldigt for man kan vel sige at det er dybt indlejret i ddbcms at et pid er unikt og ikke skifter, men det er desværre ikke tilfældet.

Og hverken opensearch eller ddbcms kan håndtere dette skift. I opensearch kan man generelt ikke søge på et gammelt pid og få den nye post.
For nogle posters vedkommende er det dog muligt, men ddbcms kan ikke håndtere at man søger på ét (gammelt) pid, men får et andet (nyt) pid retur.

PID'er for de forskellige versioner:

4.0.1
lokale poster: AGENCYID-katalog:faust
variant poster: 870970-basis:faust
(faust for lokale poster starter med 9)

3.0_4.2 (eller højere)
lokale poster: AGENCYID-katalog:faust
variant poster: AGENCYID-katalog:faust
(faust for lokale poster starter med 9)

3.5
lokale poster: AGENCYID-katalog:faust
påhængsposter: AGENCYID-katalog:faust
basisposter: 870970-basis:faust
(typen kan ikke afgøres udfra faustnummmeret)

For 4.0.1/3.0 er faustnummeret for den samme post uændret hvorimod for 3.5 får de lokale poster et nyt faustnummer.
For nogle (få?) påhængs/basis-posters vedkommende skiftes faustnummeret også.

Søgningen der fejler og som (dybt) i ddbcms benyttes for at få fat i posten:
rec.id=PID
Den benyttes når man går ind på ../ting/collection/PID eller .../ting/object/PID

Hvor ses disse poster:

  • Vedhæftede materialer og Huskeliste - som henviser til id i tabellen ting_object hvor pid'et er gemt
  • Link fra hjemmesiden eller fra Google - som f.eks. dette tilfældige link https://upgrade-alma.ddbcms.dk/ting/collection/870970-basis%3A51912586
  • Forsidekarruseller - giver dog kun fejl hvis man har benyttet PID istedet for faust
  • Lånerstatus - lidt i samme boldgade, håndteres i #2048
  • Andre steder?

Forslag til løsninger:
Forslagene udelukker ikke hinanden og hvad de evt forsøger at løse er vist i parentes.

  1. Lade det ligge: ignorer fejlen
  2. Løse det når det dukker op (vedhæftede materialer, link fra hjemmesiden, forsidekarruseller): når redaktøren bliver opmærksom på det rettes det.
  3. Løse det on-the-fly (link): hvis en rec.id=namespace:id giver fejl og namespace er bibliotekskatalog (870970-basis eller AGENCYID-katalog) så laver systemet endnu en søgning med et nyt pid (med det "andet" namespace). Alternativt at alle bibliotekskatalog PID'ere udløser søgningen: "rec.id=870970-basis:id or rec.id=AGENCYID-katalog:id".
  4. Løse det via fejl 404 (link): så tom post viser fejl 404 og man dér har mulighed for at søge videre på faustnummeret? Se #1739
  5. Løse det via cronjob (vedhæftede materialer og huskeliste): et cronjob gennemløber hele ting_object for bibliotekskatalog pid'erne og laver søgninger: "rec.id=870970-basis:id or rec.id=AGENCYID-katalog:id" - er der en ændring af namespace opdateres posten.
  6. Løse det ved en database-opdatering (vedhæftede materialer og huskeliste): der laves en opdatering på databasen med nogle SQL-UPDATE på ting_object-tabellen.

Vedr databaseopdatering:
Burde kunne løse huskeliste (så længe vi har den) og vedhæftede materialer

Ved skift til 3.0_4.2 er det enkelt da namespace skal sættes til AGENCYID-katalog på alle posterne i ting_object (som har bibliotekskatalog-namespace!).
Det kan gøres i én update-sætning

Ved skift til 3.5 (FBS) kræver det filerne fra DBC posthus, hvor der er en mapping mellem gamle og nye faustnumre for hvert agency.
Her kræver det godt nok mange update-sætninger - i værste fald en for hvert PID!
En sådan update afhænger af agency - på ét agency bliver "870970-basis:faust" måske til AGENCYID-katalog:id (påhængspost) og på et andet er det blot en basispost og uændret.

Efter en sådan opdatering kan/vil der være dubletter i ting_object men det er der underligt nok allerede i forvejen.

Konklusion
Skal vi gå efter en databaseopdatering og en bedre fejl 404?
Er der udfordringer jeg har overset?

Efter skiftet til FBS kan poster godt skifte mellem basis- og påhængsposter (så pid skifter igen) men det afhænger (vistnok kun) af en manuel katalogisering.
Det forventer jeg ikke vil ske i større omfang. Sådanne skift vil selvfølgelig ikke fanges ved en engangs-databaseopdatering.


Related issues

Related to DDB CMS - Bug #1739: Se alle eksemplarer for sletteposterResolved (tag version)
Related to DDB CMS - Bug #1698: Manglende rec.id søgeindeks på identifier stopper skift til 4.2Closed

History

#1 Updated by Rolf Madsen about 3 years ago

  • Related to Bug #1739: Se alle eksemplarer for sletteposter added

#2 Updated by Rolf Madsen about 3 years ago

  • Related to Bug #1698: Manglende rec.id søgeindeks på identifier stopper skift til 4.2 added

#3 Updated by Rolf Madsen about 3 years ago

  • Status changed from New to Ready for development

#4 Updated by Christel Krabbenhøft about 3 years ago

  • Assignee set to Laura Holm
  • Target version set to Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1)

#5 Updated by Rolf Madsen over 2 years ago

  • Target version changed from Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1) to Release 27 - Bugfixes (Inlead)

Vi afventer resultatet af #2048, og tilbageværende problemer beskrevet i dette issue kan så løses.

#6 Updated by Martin Cording over 2 years ago

  • Status changed from Ready for development to Need more info

#7 Updated by Christel Krabbenhøft over 2 years ago

Hej Laura - har I mulighed for at kigge på denne?

#8 Updated by Laura Holm over 2 years ago

  • Assignee changed from Laura Holm to Rolf Madsen

Sagen er sat på dagsordenen til Teknisk koordinationsforums næste møde. Da jeg ikke deltager i disse møder, har jeg i stedet tildelt sagen til Rolf. Mvh. Laura / DBC

#9 Updated by Rolf Madsen over 2 years ago

  • Description updated (diff)
  • Target version changed from Release 27 - Bugfixes (Inlead) to Release 29-2 - Bugfixes (Inlead)

#10 Updated by Rolf Madsen about 2 years ago

  • Status changed from Need more info to Closed
  • Assignee deleted (Rolf Madsen)
  • Target version changed from Release 29-2 - Bugfixes (Inlead) to Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1)

Dette issue løses ikke i opensearch.

Den resterende problemstilling vi kan gøre noget ved er gamle PID'er i Openlist, og det håndteres i et andet projekt.

Also available in: Atom PDF