Project

General

Profile

Bug #1698

Manglende rec.id søgeindeks på identifier stopper skift til 4.2

Added by Steen Larsen over 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
High
Assignee:
Estimated time:
URL med eksempel:
Kategorier:
Integration - Brønd - Søg, rankér filtrér sortér, Integration - Brønd - Data og relationer, Søgning - Søgeresultat efter søg - Brønd

Description

I opensearch b3.0_4.2 virker rec.id ikke.

Når man klikker på en post på et søgeresultat laves en rec.id-søgning på id'et og denne søgning fejler (giver 0 hits) med id'erne fra 4.2
Dette id er skiftet jvf #1577#note-4 og #1626#note-8

rec.id-søgningen laves dog ikke hver gang - måske noget med at det kun er første gang posten ses og derfor endnu ikke findes i tabellen ting_object?

Eksempel med 51912586 (som vi har i Aarhus, 775100)

opensearch b3.0_4.2 fejler:
rec.id=775100-katalog:51912586

opensearch 4.0.1 ok:
rec.id=870970-basis:51912586

DBC-sag 38491

rec.id_3D761500-katalog_3A07298919.png (260 KB) rec.id_3D761500-katalog_3A07298919.png Rolf Madsen, 08/18/2016 12:22 PM
rec.id_3D870970-basis_3A07298919.png (261 KB) rec.id_3D870970-basis_3A07298919.png Rolf Madsen, 08/18/2016 12:22 PM
post-oversigt.png (12.6 KB) post-oversigt.png Steen Larsen, 10/13/2016 02:16 PM

Related issues

Related to DDB CMS - Bug #1729: Funktionen ting_get_objects og opensearch 4.2Closed
Related to DDB CMS - Bug #1724: Link til relationuri bør ikke være søgningClosed
Related to DDB CMS - Bug #1721: FBS - alle manifestationer på tværs af agencies vises i værkvisningen på trods af holdingsItem.agency filterResolved (tag version)
Related to DDB CMS - Bug #1739: Se alle eksemplarer for sletteposterResolved (tag version)
Related to DDB CMS - Bug #2071: Håndtering af pid ved skift af opensearchClosed
Follows DDB CMS - Enhancement #1577: Skift til opensearch 4.2Closed

History

#1 Updated by Simon Holt over 3 years ago

> Når man klikker på en post på et søgeresultat laves en rec.id-søgning på id'et og denne søgning fejler (giver 0 hits) med id'erne fra 4.2. Dette id er skiftet jvf #1577#note-4 og #1626#note-8

Jeg skal lige være med her; Så nogle poster får nye id'er i 4.2?

#2 Updated by Steen Larsen over 3 years ago

Ja, nyt prefix - selve faustnummer er det samme
Dvs der skiftes fra 870970-basis:51912586 til 775100-katalog:51912586 (med 51912586 og AAKB 775100 som eksempel)

#3 Updated by Simon Holt over 3 years ago

Brugernes bookmarks (og vist nok også relaterede materialer indhold) er linket sammen med posternes lokale "proxy række" i ting_object tabellen via id'et 'tid'

Så dette vil vel ødelægge disse links?

#4 Updated by Steen Larsen over 3 years ago

Nej, det tror jeg ikke? Id'ere med 870970 kan jo stadig slås op

Fremtidige huskelister har dog mulighed for at indeholde tomme poster - et materiale jeg har lagt i huskeliste (under mit lokale agency som prefix) kan jo senere blive kasseret og så kan netop dén post ikke slås op (#1626) og vises i huskelisten.

#5 Updated by Simon Holt over 3 years ago

Ah ok jamen hvis de stadig kan slås op er der jo intet problem.

En post har så mulighed for at have 2 rækker i ting_object tabellen, hvis den kan slås op med 2 id'er?

#6 Updated by Gitte Barlach over 3 years ago

  • Assignee set to Rolf Madsen

Dette issue forhindrer overgang til Open Search 4.2

I Aarhus har vi afprøvet Open Search 4.2 i produktion på aakb.dk og efter blot få timer har vi skiftet tilbage til Open Search 4.0.1.
rec.id-fejlen betyder at en søgning på f.eks. nye materialer giver poster som når man klikker på titlen er en tom post evt. en fejl 404 side.
Poster som endnu ikke er kendt i systemet udløser nemlig en rec.id-søgning og det er den, der ikke virker.

#7 Updated by Steen Larsen over 3 years ago

Jeg har fået svar fra DBC og man kan ikke søge efter id på denne måde - altså med prefix "-katalog:" som vist ovenfor.

De har dog lavet en userstory så det senere bliver muligt at søge efter id'et med rec.id uden hensyntagen til prefixet. Der er ingen tidshorisont på denne opgave.
Jeg har dog ikke fået uddybet hvilken konsekvens evt. sletteposter vil få i det scenarie (men det må være det mindste af det hele)

Men hvorfor er det egentlig at vi benytter rec.id? Istedet for at benytte getObject direkte?

Jeg kan finde et sted i koden at rec.id kombineres i en længere søgestreng "rec.id=id1 OR rec.id=id2 ..." - godt nok har jeg ikke set det det i loggen, men et sådan kald er ikke nødvendigt - getObject kan håndtere flere identifiers på samme tid.

Men der er måske andre årsager?

#8 Updated by Simon Holt over 3 years ago

Der bruges rec.id= søgning ved TingCollection Requests. Fra TingClientCollectionRequest:

  public function getRequest() {
    $this->setQuery('rec.id=' . $this->id);
    $this->setAgency($this->agency);
    $this->setAllObjects(true);
    $this->setNumResults(1);

    return parent::getRequest();
  }

Den nedarver fra TingClientSearchRequest klassen, så Collection requests er bare "specielle søgninger" hvis man kan sige det sådan.

getObject bruger ved Object requsts:

  public function getRequest() {
    $parameters = $this->getParameters();
    // These defaults are always needed.
    $this->setParameter('action', 'getObjectRequest');

EDIT: Og det id der søges på ved Collection Request ser ud til at være med prefix.

#9 Updated by Simon Holt over 3 years ago

Så jeg gætter på der hvor der går galt, er når DDB CMS finder ud af, at der er mere end et object i en collection og redirecter til collection view og dermed trigger end rec.id søgning.

Det check sker efter man trykker på et materiale i søgeresultatet.

Relevant kode fra ting.module filen:

/**
 * Page callback: Display a ting collection.
 */
function ting_collection_page_view($object) {
  if (count($object->entities) < 2) {
    drupal_goto('ting/object/' . $object->id);
  }
  return ting_collection_view($object);
}

EDIT: Lige en rettelse til ovenstående. Det er omvendt. Som standard linkes der til et collection view og der redirectes til object view, hvis collection kun har 1 object.

#10 Updated by Steen Larsen over 3 years ago

Ja, søgningen laves jo ganske rigtigt i forbindelse med en collection og her ved man ikke hvor mange elementer der er deri.
Der kan være 1 (som jeg har brugt hidtil i mine tests) eller flere poster og så dur getObject jo ikke som et alternativ.

f.eks.

<searchRequest>
<format>dkabm</format>
<query>rec.id=870970-basis:51868730</query>
<stepValue>1</stepValue>
<allObjects>1</allObjects>
<agency>775100</agency>
<profile>opac</profile>
</searchRequest>

giver 1 collection med 2 poster

#11 Updated by Simon Holt over 3 years ago

Så lige for at opsummere er et af problemerne ved opgradering til opensearch 4.2 at klik på posterne i et søreresultat giver en tom post/404 hvis:

Resultatet (collectionen) indeholder mere end én post og der derfor ikke redirectes til ting_object view (der ville bruge getObject()).

Der har ikke noget at gøre med om posten er kendt i forvejen. Grunden til at det virkede for Gitte i ovenstående, må være fordi nogle poster har ligget i cachen og det derfor ikke har været nødvendigt at lave rec.id søgning. Så snart posterne bliver fjernet fra cachen, vil disse også give tom post, da systemet igen skal lave en rec.id søgning med opensearch.

#12 Updated by Steen Larsen over 3 years ago

En drush clear-cache udløser søgningen med rec.id som udføres hver gang man klikker på et link med /ting/collection/ (f.eks. fra en søgeresultatside) og den side der så vises kan evt - afhængig af resultatet - kan viderestilles til en /ting/object-side.

Men der er tilsyneladende også lidt tilfældighed her - nogle faustnumre kan faktisk søges med rec.id hvilket må være årsagen til at vi ikke opdagede problemet lige med det samme da vi forsøgsvis skiftede (note-6)

Søgning direkte i opensearch http://opensearch.addi.dk/b3.0_4.2/:
rec.id=775100-katalog:51912586 fejler
rec.id=775100-katalog:27364896 ok

Vi må nok afvente DBC her.

#13 Updated by Steen Larsen over 3 years ago

Så er der kommet et forslag fra DBC - man ikke kan søge med rec.id på den måde, så der er et forslag til hvad der så kan gøres.


Fra 4.2 fås:

775100-katalog:26476720
870970-basis:26476720
active

dkabm
marcxchange


775100-katalog:26476720
870970-basis:26476720

Identifier'en der står i det øverste identifier-element (775100-katalog osv.) er ændret i 4.2 af hensyn til funktionalitet i brønd 3.5.
I tidligere versioner stod identifier'en med 870970-basis som namespace.
Identifier'en i øverste identifier-element kan kun bruges til getObject-kald, ikke søgning.

Til søgning kan identifierne under objectsAvailable benyttes, dvs

rec.id="775100-katalog:26476720" OR rec.id="870970-basis:26476720"


Men det forslag løser vist ikke dette issue - objectsAvailable-objecter har vi kun efter søgningen er gennemført. Har vi kun linket: /ting/collection/ findes kun værdien fra identifier (den øverste)

En løsning skal også være uændret i forhold til FBS og alle de øvrige kilder og tage højde for både de lokale faust (som kun findes i en katalog-version) og centrale poster (som eksemplerne ovenfor).

Så hvordan vi i DDBCMS får lavet en løsning har jeg ingen bud på, så andre må vist træde til for yderligere analyse/løsning.

#14 Updated by Rolf Madsen over 3 years ago

  • Status changed from New to Needs analysis
  • Target version set to DDB CMS 2017 1. opgradering (7.x-4.0.2)
  • Kategorier Integration - Brønd - Søg, rankér filtrér sortér, Integration - Brønd - Data og relationer added

#15 Updated by Steen Larsen over 3 years ago

Titlen på dette issue bør måske snarere være "Manglende søgeindeks på identifier stopper skift til 4.2"

Jeg har fundet en andet type link som også rammes - og skal ændres:

På denne tidsskriftartikel https://vanilla-alma.ddbcms.dk/ting/object/870971-tsart%3A35746560
er der link i detaljerne ("Available in") til tidsskriftet "Komputer for alle, 2013, nr. 13"
https://vanilla-alma.ddbcms.dk/search/ting/870970-basis%3A49205058
altså en søgning på selve identifier: 870970-basis:49205058
Det virker ikke i 4.2 hvor det ser sådan ud: -katalog:49205058 (hvor agencyid for aarhus jo så er 775100)

Løsningen er måske at lave linket til et opslag dvs /ting/object/ istedet for /search/ting/ - det burde virke her, men jeg ved ikke om det er en generel løsning for "Available in"-feltet

#16 Updated by Martin Cording over 3 years ago

Husk at godt kan være f.eks. 775100-katalog:51912586, selvom kan være 870970-basis:51912586.

Hvorfor ikke bruge rec.id=FAUST istedet for rec.id=PID?

#17 Updated by Steen Larsen over 3 years ago

Jeg har oprettet en sag med #1698#note-15 i #1724

#18 Updated by Steen Larsen over 3 years ago

"Workflowet" for en søgning består af to dele:

1) en søgning foretages og der vises 10 poster. Link til disse oprettes på basis af feltet identifier. Linkskabelonen er /ting/collection/

2) et collection-link klikkes. Udfra oplysningerne fra urlen (dvs identifier incl. namespace) laves søgninger efter posterne i værket/værkmatch og der vises enten en collection-side (/ting/collection/) eller en object-side (ting/object) afhængig af antallet.

Tiden mellem 1) og 2) kan være alt fra 1 sek til 1 år (eller mere) så der er kun oplysningerne fra urlen vi kan benytte i 2) - der er ikke gemt noget i session/cache o.lign.

Identifier kan være ret meget - også noget der ikke indeholder faustnumre.
Men i tilfældet hvor prefix i id'et indeholder "-katalog" eller "-basis" så er det vel netop faustnummer?

Samme eksempel fra note13 incl. ac:identifier

<object>
   <dkabm:record>
      <ac:identifier>26476720|870970</ac:identifier>
      ...
   </dkabm:record>
   <identifier>775100-katalog:26476720</identifier>
   <primaryObjectIdentifier>870970-basis:26476720</primaryObjectIdentifier>
   <recordStatus>active</recordStatus>
   <formatsAvailable>
      <format>dkabm</format>
      <format>marcxchange</format>
   </formatsAvailable>
   <objectsAvailable>
      <identifier>775100-katalog:26476720</identifier>
      <identifier>870970-basis:26476720</identifier>
   </objectsAvailable>
</object>

Jeg tror ikke man blot kan bruge primaryObjectIdentifier istedet i 1) - det er ikke den værdi som man får og benytter i #1724

#19 Updated by Rolf Madsen over 3 years ago

  • Subject changed from Rec.id-søgning i 4.2 virker ikke to Manglende rec.id søgeindeks på identifier stopper skift til 4.2

#20 Updated by Steen Larsen over 3 years ago

En løsning kunne være denne i forbindelse med rec.id-søgningen:

  1. Identifier i form af NAMESPACE:ID haves (f.eks. fra urlen)
  2. Søgeudtryk konstrueres (som nu): rec.id=NAMESPACE:ID
  3. Hvis namespace ender på "-katalog" tilføjes " or rec.id=870970-basis:ID" til søgeudtryk
  4. Søgningen foretages

Uafklarede spørgsmål:

  • hvordan virker løsningen i FBS (dvs opensearch b3.5_4.2)
  • sletteposter - men det bør være uforandret i forhold til nu, da det er en søgning (selvom #1721 viser noget andet)
  • andre kilder - bør ikke være anderledes end i dag
  • er der andre steder i koden hvor søgning med rec.id eller identifier foretages (bortset fra #1724 som håndteres hvis løsning a) benyttes)

#21 Updated by Simon Holt over 3 years ago

> Hvorfor ikke bruge rec.id=FAUST istedet for rec.id=PID?

Hvad med det forslag? Det ville da være det nemmeste. Men er der fare for kollisioner måske?

#22 Updated by Martin Cording over 3 years ago

  • Assignee changed from Rolf Madsen to Kirstine Wilfred Christensen

Kan du komme med dit input her, Kirstine?

#23 Updated by Steen Larsen over 3 years ago

Det kunne selvfølgelig være værd at undersøge.
Men det vil dog kun ændre lidt på mit forslag: 3. Hvis namespace ender på "-katalog" skal søgeudtryk være rec.id=ID
ID er (vist) kun faust når namespace indeholder katalog eller basis.

Fra anden side ved jeg at DBC starter analyse/udvikling på rec.id-sagerne i næste uge.

#24 Updated by Kirstine Wilfred Christensen over 3 years ago

Jeg tror ikke jeg vil blande mig yderligere, Martin. Steen har allerede kontakt til Bodil (og derved Linda) fra min afdeling via vores servicedesk og som nævnt er der defineret en userstory på problematikken.

#25 Updated by Rolf Madsen over 3 years ago

  • Assignee changed from Kirstine Wilfred Christensen to Laura Holm
  • Priority changed from Normal to High
  • Target version changed from DDB CMS 2017 1. opgradering (7.x-4.0.2) to DDB CMS 2016 2. opgradering (DBC sprintbacklog)

#26 Updated by Simon Holt over 3 years ago

> er der andre steder i koden hvor søgning med rec.id eller identifier foretages (bortset fra #1724 som håndteres hvis løsning a) benyttes)

Ja. Metoden ting_get_objects() fra ting.client.inc kan finde på at bruge rec.id søgning:

  // Not all object are searchable, such as relation etc. So to get over this we
  // split the request into to groups "own id's" and "others". Where the first
  // is ensured to be searchable.
  $agency = variable_get('ting_agency', FALSE);
  $query = array();
  foreach ($objects as $id => $object) {
    if ($object === FALSE) {
      // So if the agency match lets search theme as that's faster then fetching
      // them one by one.
      if (preg_match('/^(890790-basis|' . $agency . '-katalog|' . $agency . ')/', $id)) {
        $query[] = 'rec.id=' . $id;
      }
      else {
        // Get objects as it was not local.
        $objects[$id] = ting_get_object($id);
      }
    }
  }

ting_get_objects() bliver kaldt når der loades flere ting objects via ding_entity_load_multiple(). Dette ser ud til at være gældende ved reseravationslisten og lånestatus.

#27 Updated by Steen Larsen over 3 years ago

Måske behøver ting_get_objects ikke at lave søgninger men kan lave opslag direkte via getObjectRequest.
Feltet identifier i requestet kan jo gentages for hvert id. Måske en ny ny sag/opgave.

#28 Updated by Simon Holt over 3 years ago

Så vidt jeg kan se, har man lavet funktionen for at opnå en forbedring i performance ved at klare flere objects i et søgerequest på formen "rec.id= OR rec.id=...."
Hvis man fjerner dette, bliver funktionen meget simplicificeret og gør egentlig ikke noget anderledes en ting_get_object().

Har ikke testet det, men tror også materialerne vil blive vist fint alligevel, da kaldet til ding_entity_load_multiple() her benyttes til at pre-loade objekterne. Men vi burde nok alligevel fjerne/ændrer kaldet (da det jo så ikke har nogen effekt) og rette ting_get_objects(), hvis der er andre moduler der vil bruge den.

#29 Updated by Steen Larsen over 3 years ago

Har oprettet #1729 mht ting_get_objects

#30 Updated by Rolf Madsen over 3 years ago

  • Related to Bug #1729: Funktionen ting_get_objects og opensearch 4.2 added

#31 Updated by per johansen over 3 years ago

Denher kan jeg ikke genskabe. Jeg kan ikke finde nogen brudte links på vanilla-alma.ddbcms.dk, og ditto på min lokalinstallation (som forresten kører lynbørgehurtigt på php7).

Jeg snakker med linda eller bodil imorgen for lige at høre om der er blevet fixet et eller andet. Hvis en af jer kan give mig et eksempel eller to fra vanilla-alma hvor det ikke virker giver jeg en flødebolle.

#32 Updated by per johansen over 3 years ago

okay .. jeg giver mig selv en flødebolle.

#33 Updated by per johansen over 3 years ago

umiddelbart stemmer jeg for løsningen med at bruge rec.id=faust. Men jeg snakker lige med de kloge imorgen for at høre om det kan have utilsigtede bivirkninger

#34 Updated by Steen Larsen over 3 years ago

Øv, der var jeg ikke hurtig nok

Glem ikke #1721, #1724 og #1729

Mht til at bruge faust vil det vel alligevel kræve særlig håndtering?

I min kommentar i nærværende sag #1698#note-20

  1. Identifier i form af NAMESPACE:ID haves (f.eks. fra urlen)
  2. Søgeudtryk konstrueres ...
  3. Søgningen foretages

er ID jo ikke altid FAUST

#35 Updated by per johansen over 3 years ago

okay nu har jeg snakket med de kloge. Hvis vi bruger rec.id=faust risikerer vi at få støj. Løsningen er sådan her:

foreach ($pids as $pid) {
$id_array[] = $pid;
list($owner, $id) = explode(':', $pid);
$id_array[] = '870970-basis:' . $id;
}

så kommer der to pid'er i id_array fx. [775100-katalog:11111111, 870970-basis:11111111]
og de skal så kombineres til en OR søgning

Jeg går igang med implementationen

#36 Updated by Steen Larsen over 3 years ago

Hmm, hvad med andre kilder - kan vi altid være sikre på at ID i "NAMESPACE:ID" fra en anden kilde (anden NAMESPACE) aldrig er et eksisterende faustnummer?
Og hvad med eksisterende 870970-objecter?

#37 Updated by per johansen over 3 years ago

jeg støtter mig til de kloge (Finn og Linda). Og selvfølgelig skal eksisterende 870970 numre ikke laves om.

#38 Updated by Steen Larsen over 3 years ago

Jeg støtter mig også gerne til dem :-)

Et eksempel til at understøtte mit spørgsmål:

https://www.aakb.dk/ting/collection/150043-atlas:10239

skal jo ikke give dette søgeudtryk:

rec.id=150043-atlas:10239 or rec.id=870970-basis:10239

#39 Updated by per johansen over 3 years ago

hmm ...

#40 Updated by per johansen over 3 years ago

Linda giver svaret - det er kun hvis biblioteksnummeret matcher at søgningen skal OR'es

#41 Updated by per johansen over 3 years ago

  • Status changed from Needs analysis to Needs code review
  • Assignee changed from Laura Holm to Kasper Garnæs

getObjectRequest handles missing search indexes

done a pull request
https://github.com/ding2/ding2/pull/240

#42 Updated by Simon Holt over 3 years ago

Hej Per,

Hva med rec.id søgningen foretaget i TingClientCollectionRequest klassen? Det er den, der er problemet, når man klikker på et materiale i søgeresultatet:

https://github.com/ding2/ting-client/blob/master/lib/request/TingClientCollectionRequest.php#L23

ting_get_objects(), som du omdøber til ting_do_get_objects() i dit PR, ser ud til på nuværende tidspunkt kun at blive kaldt i Ctools plugins for reservations og låneliste (via ding_entity_load_multiple()). Og her ser det ud til bare at være for at preloade objekterne til cachen, så materialerne bliver sikkert vist fint alligevel der. Den laver bare et unødvendigt kald, hvis ting_get_objects() ikke virker alligevel ved skift til 4.2.

#43 Updated by Steen Larsen over 3 years ago

Øh, overser jeg et eller andet? Er søgning med rec.id forsvundet?
Har du fundet en anden vej til målet? Eller løst en anden sag?

Årsagen til at vi først søger efter id'et skyldes at vi skal have alle materialerne i værket - med allObjects?

https://www.aakb.dk/ting/collection/870970-basis:26755522


rec.id=870970-basis:26755522
1
allObjects>1
775100
opac

#44 Updated by per johansen over 3 years ago

jaarhhh - jeg har jo ikke omdøbt den, men lavet en ny metode som bliver kaldt fra ting_get_objects .. for læsbarhedens skyld, og den laver rent faktisk et opslag hvis cachen ikke findes.

Udover det har jeg fjernet collectionrequesten fra mit sidste commit
https://github.com/ding2/ding2/pull/240

Og nu virker det. Jeg giver en flødebolle hvis det fejler.

#45 Updated by Steen Larsen over 3 years ago

allObjects?

#46 Updated by per johansen over 3 years ago

jamen altså - jeg må give en flødebolle - eller flere .. allObjects hvad gør den egentlig - jeg finder ud af det giv mig 5 minutter

#47 Updated by per johansen over 3 years ago

jahh den kan fixes - jeg laver lige et par commits mere lige om lidt

#48 Updated by Simon Holt over 3 years ago

> jaarhhh - jeg har jo ikke omdøbt den, men lavet en ny metode som bliver kaldt fra ting_get_objects
My bad

> og den laver rent faktisk et opslag hvis cachen ikke findes.
Yes I know - det jeg snakker om med at preloade er kaldet til ding_entity_load_multiple() i plugin'erne til listerne i reservations/status. Disse kald bør måske fjernes nu, men nevermind det er ikke så relevant i denne sag.

> Udover det har jeg fjernet collectionrequesten fra mit sidste commit
Tror ikke det er smart bare at fjerne den?

#49 Updated by Steen Larsen over 3 years ago

Det er #1729 hvor man måske kan gøre tingene lidt mere effektive med et samlet kald til getobject en det er ikke issuet i nærværende sag.

#50 Updated by Simon Holt over 3 years ago

Jeg synes vi bør nævne og overveje alle de steder i systemet, hvor de ændringer der er ved at blive lavet her kan have en effekt.

#51 Updated by per johansen over 3 years ago

okay jeg har genindsat collectionRequesten her
https://github.com/ding2/ding2/pull/240

og så har jeg hacket lidt i ting-client her:
https://github.com/ding2/ting-client/pull/18

og så snakker jeg med Finn om vi ikke kan få en allObjects på getObject requesten - det vil vist være den rigtige løsning

@simon du har ret. Men searchrequest på rec.id virker jo ikke, så det er ret vigtigt at bruge getObject istedet - hvor det nu kan lade sig gøre

#52 Updated by Steen Larsen over 3 years ago

Er der kommet nye oplysninger til? Måske fra brønd 3.5?

Eller virker søgning med rec.id alligevel ikke som beskrevet i tidligere løsningsforlag?

Ses f.eks. i note20 hvor der kigges på NAMESPACE og hvor søgning håndteres specielt hvis NAMESPACE begynder med et agency (f.eks. "775100") eller slutter på "-katalog" (dvs en "or"-søgning mellem to rec.id udtryk).

Når getObject nævnes hvad så med sletteposterne? De slås fint op men kan (stadig) ikke søges frem.
Jeg har godt nok opgivet at håndtere dem (#1626) men de skulle jo ikke gerne dukke op i større mængde end i dag.

#53 Updated by Laura Holm over 3 years ago

Svar fra Finn (DBC OpenSearch):
allObjects kan ikke være en parameter på getObject kaldet. Formålet med getObject er at få en specifik manifestation.

Vil man bruge værk-iferingen, så skal man bruge search kaldet.

Tanken er at man søger, får et kort oversigtsformat for de manifestationer man viser fra værket. En efterfølgende "se-mere" operation i klienten, medfører et getObject kald for netop den manifestation.

Men, der er intet der forhindrer i at man søger på en post idnr, istedet for at bruge getObject, hvis det er værkificeringen man ønsker (med eller uden allObjects)

/Finn

Og fra Per Dscrum:
staus på issue 1698 er code-review. Jeg synes vi skal lade core-team vurdere om de ændringer jeg har lavet vil løse problemet (hvad jeg er ret sikker på).

I issue 1698 er flere andre problemer taget op fx. sletteposter, som jeg mener er irrelevant for denher.

#54 Updated by Steen Larsen over 3 years ago

Ok, tak for opdateringen.
Jeg havde netop løbende flyttet andre issues til nye sager så nærværende sag kun er det med rec.id-søgningen.
Min kommentar gik på "Men searchrequest på rec.id virker jo ikke" i note 51, men løsningen i pullrequestet er netop som tidligere beskrevet i nærværende sag (så vidt jeg kan se).

#55 Updated by Steen Larsen over 3 years ago

Øv, glemte dette...
Sag #1729 er jo - som nævnt ovenfor - relateret til nærværende sag, da der også dér benyttes søgning med rec.id
Måske bliver #1729 faktisk løst af det første pullrequest som netop ændrer funktionen ting_get_objects

#56 Updated by Gitte Barlach over 3 years ago

  • Assignee changed from Kasper Garnæs to Jesper Kristensen

#57 Updated by Gitte Barlach over 3 years ago

Sag #1729 og sag #1724 skal endvidere også løses før vi kan skifte til 4.2.

#58 Updated by Jesper Kristensen over 3 years ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Jesper Kristensen to per johansen

Reviwed med nogle forskellige issues der lige skal svares på og tages hånd om.

Steen og Simon har i noget til denne, da det virker til i osse har arbejde med dette.

#59 Updated by per johansen over 3 years ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from per johansen to Jesper Kristensen

jeg har fixet scrutinizer .. circleCi melder en fejl i bygget af themet ??

#60 Updated by per johansen over 3 years ago

så er der ingen fejl i circleCi og scrutinizer

#61 Updated by Simon Holt over 3 years ago

@Jesper

Jeg synes det ser fint ud. ting_get_objects bruger nu ikke længere rec.id søgninger men bruger i stedet getObjectRequest.

Det eneste jeg studser lidt over er, at der passes et array med id'er til TingClientObjectRequest's setObjectId() metode. Når jeg kigger på klassen ser den umiddelbart ud til at forvente et enkelt ID, men Per har sikkert testet at det virker alligevel?
EDIT: Kom til at se at nanosoap modulet selvfølgelig fint håndterer at man passer et array som parameter. Det er måske lidt misvisende, at metoden på TingObjectRequest klassen hedder setObjectId (og ikke setObjectIds). Det forvirrede i hvert fald mig :)

#62 Updated by Jesper Kristensen over 3 years ago

Aarhus arbejder PT. på at undersøge sagen i bund mm. Så afvent lige os før der skal ske mere.

#63 Updated by Gitte Barlach about 3 years ago

  • Status changed from Needs code review to 8
  • Assignee changed from Jesper Kristensen to Gitte Barlach

#64 Updated by Gitte Barlach about 3 years ago

Jeg vil foreslå at vi tager #1729 med ind under denne sag.

#65 Updated by Thomas Hansen about 3 years ago

Sig mig, er en brønd id, en brønd id, eller hvad? Indeholder det et faust nummer, eller gør det ikke? Hvad kan man søge på og hvad virker ikke?

Som jeg allerede var inde over i #1729, så skal der altså lige strammes lidt op. Som en der sidder på sidelinjen og altid er den sidste der får noget at vide, er det her rimelig uoverskueligt.

Hvis der skal alt mulig mumbojumbo med prefixer til for at lave en søgning, så skal det dokumenteres i kommentarne i ting koden, hvad, og hvorfor. Det her med "X siger at man skal gøre sådan her" og "det her virker ikke, men det her gør" er ikke godt nok.

Prefikser er åbenbart et rimeligt vigtigt begreb i brønden. Det er ikke nævnt med et ord i ting modulet. ding_provider prefikser rent faktisk IDer fra providerne. Der er ordet prefix heller ikke brugt. Der er nogen prefikser der tydeligvis har en speciel rolle. Det er heller ikke nævnt nogen steder.

Som jeg ser det, er der to steder en "brønd id" kan komme fra når den rammer ting.module:

1. En søgning, hvilket også i sidste ende vil sige hvis man går direkte ind på et værk/materiale.
2. Provideren.

2eren er (oftest) et u-prefikset faust nummer, der skal logisk nok et eller andet logik til at lave et prefikset id, men når det er gjort, så er det bare at lange den videre til brøneden.

1eren er IDer der kommer direkte fra brønden selv. Hvorfor pokker skulle vi rode med prefikser der? Burde de ikke være som de skal være?

Tydeligvis er der noget i den forståelse der ikke holder, for ellers burde al prefiks håndering i ting.module være unødvendig.

Hvis ting.module skal rode med prefikser, så skal det først og fremmest dokumenteres hvad de er, hvilke der er specielle og hvorfor vi roder med dem. Så får vi også større overblik over hvordan det er i forhold til søgning/getObject..

#66 Updated by Martin Cording about 3 years ago

FYI:
PID = Brønd ID (består af kilde + FAUST, adskilt af kolon), f.eks.: 870970-basis:26755522
FAUST = FAUST, f.eks.: 26755522

#67 Updated by Thomas Hansen about 3 years ago

Joe, det har jeg efterhånden regnet ud, men hvordan er det lige at en ny udvikler skal finde ud af det?

Og det er så heller ikke helt rigtigt, Steen påpeger at der er nogen tilfælde hvor det ikke er et FAUST nummer.

Pointen med min kommentar var:

1. Ideelt set burde ting.module ikke bekymre sig sig om kilder, men det lader til det sniger sig ind alligevel, og så skal det altså gøres ordenligt og dukumenteres.
2. Det skal dokumenteres i koden, og
3. Det skal dukumenteres i koden.

#68 Updated by Steen Larsen about 3 years ago

Ja, jeg er enig i at det skal dokumenteres
Hvordan en løsning overordnet skal strikkes sammen ved jeg endnu ikke.

En opdatering fra DBC:
DBC vil igen gøre det muligt at søge efter identifier i 4.2 - altså identifier af typen: "agencyid-katalog:id" så rec.id= igen kan bruges. De nye indeks er endnu ikke lagt ind.

Det er et skridt på vejen men jeg kan ikke lige se en løsning på at vi søger på en identifier men får en anden identifier retur.
Måske ved at bruge primaryObjectIdentifier men det kan give andre udfordringer. Jeg tager det op med DBC efter ferien.

#69 Updated by Rolf Madsen about 3 years ago

  • Related to Bug #1724: Link til relationuri bør ikke være søgning added

#70 Updated by Rolf Madsen about 3 years ago

Jeg har netop testet den seneste version af Opensearch, der nu kører mod driftsbrønden.

Konfiguration:
Library code: 761500
Search service URL: http://opensearch.addi.dk/b3.5_4.3/
Search profile: opac

Søgninger på materiale der findes både som basis- og katalogpost

https://vanilla-fbs.ddbcms.dk/search/ting/rec.id%3D761500-katalog%3A07298919

https://vanilla-fbs.ddbcms.dk/search/ting/rec.id%3D870970-basis%3A07298919

I begge tilfælde vises katalogposten med de lokale tilretninger.

#72 Updated by Steen Larsen about 3 years ago

Det lyder godt og er et skridt på vejen.

Med den nye 4.3 er det måske også kommet nogle muligheder som måske kan lette overgangen fra 4.0.1 til 4.3 men det kan jeg ikke gennemskue nu (eller senere).

Husk også at med disse tests at være opmærksom om det er gemt i cachen.
Prøver man at slå et object op som allerede er i cachen kan det jo ret nemt give et forkert signal om noget virker eller ikke.

#73 Updated by Rolf Madsen about 3 years ago

  • Related to Bug #1721: FBS - alle manifestationer på tværs af agencies vises i værkvisningen på trods af holdingsItem.agency filter added

#74 Updated by Rolf Madsen about 3 years ago

  • Target version changed from DDB CMS 2016 2. opgradering (DBC sprintbacklog) to DDB CMS 2016 2. opgradering

#75 Updated by Rolf Madsen about 3 years ago

  • Status changed from 8 to Technical test

#76 Updated by Rolf Madsen about 3 years ago

#77 Updated by Steen Larsen about 3 years ago

Man kan som nævnt søge både på rec.id=870970-basis:ID og på rec.id=775100-katalog:ID og få én post retur.

I #1729#note-23 nævnes at ddbcms efter en søgning "leder" efter det pid der faktisk er søgt efter med rec.id og benytter det fundne object til cachen.
Det giver en udfordring når der ledes efter det ene pid og det er det andet pid der returneres.

En løsning kunne måske være at droppe dette og uanset hvad altid benytte den ene post der returneres.
Det betyder desværre at man ikke kan kombinere flere pid i en længere søgning (men den kode var der også fejl i selvom jeg ikke lige kan finde hvor det er nævnt).

Men ellers har jeg ikke nogle bud på mulige veje fremad for disse sager

#78 Updated by Steen Larsen almost 3 years ago

Lige for at opsummere hvad løsningen f.eks. skal håndtere.

I version 4.3 kan vi stå med to urler / to poster

(1) /ting/object/775100-katalog:51912586
(2) /ting/object/870970-basis:51912586

(1) vil f.eks. være posten fra en søgning i 4.3 og (2) kan være et link fra indhold på hjemmesiden, google eller et helt tredje sted (altså tidligere fundet ved søgning i 4.0.1)

Mangler de i cachen foretages disse to søgninger

rec.id=775100-katalog:51912586

rec.id=870970-basis:51912586

som her hver især returnerer den samme post:

<object>
 <dkabm:record>
    <ac:identifier>51912586|870970</ac:identifier>
    <dc:identifier>REO Universal UNI 4747065</dc:identifier>
    <ac:source>Bibliotekskatalog</ac:source>
    <dc:title>Godt nyt</dc:title>
    <dc:title xsi:type="dkdcplus:full">Godt nyt</dc:title>
...
 </dkabm:record>
 <identifier>775100-katalog:51912586</identifier>
 <primaryObjectIdentifier>870970-basis:51912586</primaryObjectIdentifier>
 <recordStatus>active</recordStatus>
 <formatsAvailable>
    <format>dkabm</format>
    <format>marcxchange</format>
 </formatsAvailable>
 <objectsAvailable>
    <identifier>775100-katalog:51912586</identifier>
    <identifier>870970-basis:51912586</identifier>
 </objectsAvailable>
</object>

#79 Updated by Simon Holt almost 3 years ago

Noget andet der måske er værd at nævne er at de to opslag:

(1) /ting/object/775100-katalog:51912586
(2) /ting/object/870970-basis:51912586

Også vil resultere i to rækker i ting_object tabellen, der i virkeligheden peger på den samme post.

Kan ikke lige gennemskue om det har nogle konsekvenser udover at der bare kommer endnu flere rækker i tabellen (vi har næsten 4 millioner rækker i den på nuværende tidspunkt).

Note: ding_bookmark benytter entity id'erne fra ting_object tabellen til at associere materialer fra brønden med brugere til huskelisten. Men det er jo på vej ud.

#80 Updated by Thomas Hansen almost 3 years ago

@simon
775100-katalog:51912586 og 870970-basis:51912586 er jo reelt ikke det samme hvis biblioteket har rettet lidt i den lokale (som jeg forstår at grunden til at der er to versioner af samme materiale), samtidig med at jo er precis samme materiale... Den lokale skulle vel skygge for den globale.

Der begynder brøndens koncept model lidt at bryde sammen, og overlader problemet til DDB CMS. Hvordan har Den Åbne Platform tænkt sig at håndtere problemet? For det er vel precis den slags spisfindigheder den er sat i verdenen for at håndtere?

#81 Updated by Simon Holt almost 3 years ago

> 775100-katalog:51912586 og 870970-basis:51912586 er jo reelt ikke det samme hvis biblioteket har rettet lidt i den lokale (som jeg forstår at grunden til at der er to > > versioner af samme materiale), samtidig med at jo er precis samme materiale... Den lokale skulle vel skygge for den globale.

Ok.. jamen det giver jo god mening, hvis det forholder sig sådan. Jeg troede det havde noget at gøre med, at beholdningsdata nu er (bedre) integreret med brønden og at de nye pr. agency unikke id'er, skulle bruges til at kæde det sammen med det. Men må tilstå, at jeg ærligt talt ikke ved ret meget om, hvordan det hele er strikket sammen omme bagved. Så for mig er det ofte en gætteleg, hvilket er noget frustrerende.

@Steen
Det virker som om, at du har fingeren på pulsen med det her. Kan du kaste lidt lys over det her med de nye id'er? For synes aldrig det rigtigt er blevet forklaret nogle steder.

Og har fuldstændig mistet overblikket i disse sager. Nu hvor rec.id søgning tilsyneladende er fikset i 4.2, hvad er der så tilbage af problemer ved skift til nyere version?

Vi står f.eks. og skal til at opdater vejlebib.dk. Vi bruger i øjeblikket 4.0.1 og jeg kigger lidt på muligheden for at opdatere. Kan se at der også er en brønd 3.0 version af 4.2 og 4.3. Kan vi skifte til dem? Er der også forskellige id'er i disse version eller er det kun dem der kører med brønd 3.5?

#82 Updated by Steen Larsen almost 3 years ago

Så vidt jeg kan gennemskue så opstår problemet ikke mere når det drejer sig om nye søgninger - disse vil returnere poster som alle (senere) kan søges frem igen via rec.id=...

Problemet opstår ved "gamle poster" - dvs hvor id (f.eks. 775100-katalog:12345678 eller 870970-basis:87654321) er gemt.
Det kan være i et link (af google, indhold på hjemmesiden) eller i en tabel (huskeliste, vedhæftede materialer, andre oversigter?)

Jeg har prøvet at lave en oversigt hvor jeg bruger vores (aarhus') agency 775100 som demo
Og det er kun bibliotekskatalog-poster - øvrige kilder har deres eget prefix

Definitioner:
Lokal post - en post som kun vi har - ofte oprettet af os selv
Variant post - en post der enten kan være en basispost eller en modificeret/tilrettet basispost
Påhængspost - en modificeret basispost
Basispost - den officielle post hos DBC

Ved skift til FBS får lokale poster nye numre og en variantpost bliver til enten en påhængspost eller en basispost.

Når vi taler om at skifte til 4.2 er det faktisk skift til seneste version som pt. er 4.3

Se vedlagte "post-oversigt.png"
Her betyder (1) at posten kan søges frem men det er posten med 775100-katalog der returneres.

Ved at kigge i overisgten kunne man udlede det her (håber jeg):

Skift fra 4.0.1 til 4.3, brønd 3.0
Gamle lokale kan søges
Gamle variant kan søges (rec.id=870970-basis:...) men det er 775100-katalog der returneres fra opensearch

Skift fra 4.0.1 til 4.3, brønd 3.5
Gamle lokale får nyt faust og kan ikke søges
Gamle variant (rec.id=870970-basis:...) kan søges:

- hvis posten er blevet til en påhængspost returneres 775100-katalog
- hvis posten er blevet til en basispost returneres 870970-basis

Skift fra 4.3, brønd 3.0 til brønd 3.5
Gamle lokale poster får nyt faust og kan ikke søges
Gamle variant poster (rec.id=775100-katalog:...):

- hvis posten er blevet til en påhængspost giver søgningen posten 775100-katalog
- hvis posten er blevet til en basispost giver søgningen intet

Så udfordringen er, at der for nogle posters vedkommende, søges på ét id og man får enten et andet id eller intet retur.
Men hvor ligger disse og hvor mange er der? Dvs hvor stort vil problemet være?

#83 Updated by Rolf Madsen almost 3 years ago

Jeg har skrevet til DBC for at undersøge om der er noget vi kan gøre.

#84 Updated by Steen Larsen almost 3 years ago

Der er nogle ting at undersøge:

  1. Hvis vi har et id fra en url, søger på det med rec.id og får et andet id retur (som beskrevet ovenfor) - er det så muligt (i ddbcms) at omsætte det til en redirect til den rigtige post (nemlig den der blev fundet)?
  2. Hvis vi har et faust (for brønd 3.5) er der vist intet der signalerer hvilke af de 3 typer poster det er.
    Her kunne det måske være godt hvis vi fik et indeks (i opensearch) således, at selvom det er en basispost så kan man alligevel søge med 775100-katalog og få et resultat (nemlig posten med 870970-basis) - det betyder at man altid kan søge efter rec.id=775100-katalog:... for alle faustnr.
  3. Og så er der alle de gamle faustnumre som ved skiftet til FBS får nye numre - er det muligt i opensearch at få et indeks så man stadig kan søge efter dem? Og selvfølgelig få den rigtige post med det nye id?

Punkt 2+3 giver nok kun rigtig mening hvis punkt 1 er en (realistisk) mulighed.

#85 Updated by Gitte Barlach almost 3 years ago

  • Status changed from Technical test to 8
  • Assignee changed from Gitte Barlach to Rolf Madsen

På baggrund af Steens seneste opdatering i sagen, foreslår jeg at vi etablerer et møde m. deltagelse af relevante teknikere samt data/brøndeksperter fra DBC, så vi opnår consensus omkring en løsning, hvorefter sagen kan sendes til udvikling.

#86 Updated by Steen Larsen almost 3 years ago

I note-82 står at situationen med "Søg på ét id og få et andet retur" kun opstår ved gamle poster.

Det er ikke korrekt

Når systemet henter lånerstatus for en given låner returneres faustnumre - intet prefix. Man kan jo i koden for brønd 3.0-4.3 sætte prefix til 775100-katalog og det kan håndteres.
Men for brønd 3.5-4.3 er dette ikke muligt. Påhængsposter/lokale poster har 775100-katalog og basisposterne har 870970-basis som prefix.
Hvis jeg antager at vi kan få indekset fra note84, pkt 2 så kan prefix sættes til 775100-katalog og vi kan altid få et hit (men når det er en basispost dog et andet id)

Så ddbcms bør kunne håndtere "Søg på ét id og få et andet retur"

Man kunne selvfølgelig overveje om der - også - skal gøres noget specielt for de gamle poster, f.eks. med en redirect for eksterne urler (note84, pkt 1) eller en (drupal)tabelopdatering for huskelister/vedhæftede materialer.

For i øvrigt så ses den manglende funktionalitet som blanke poster - dvs huskelister, nyheder med vedhæftede materialer og eksterne link til poster er tomme uden titel, forfatter og alle øvrig info.
Lånerstatus virker delvis, fordi der er fallback til at benytte oplysningerne fra provideren - det virker for alma, men ikke for fbs.
Et skift er nemt at teste på en testserver - man skal blot huske at slette cache, så søgningerne med rec.id gennemføres og så være opmærksom på hvilken type post man kigger på jvf post-oversigten i note-82.

Jeg kan ikke overskue om bøtten skal vendes og det skal gøres på en helt anden måde. Årsagen til at vi laver søgningen er fordi vi skal have fat i hele værket som så caches.

#87 Updated by Rolf Madsen almost 3 years ago

  • Target version changed from DDB CMS 2016 2. opgradering to DDB CMS 2017 1. opgradering (7.x-4.0.2)

#88 Updated by Steen Larsen almost 3 years ago

Har spurgt DBC om søgningen rec.id=775100-katalog:FAUST for en given basispost kunne være en mulighed for brønd3.5_4.3 med et nyt indeks.
Resultatet vil så være 870970-basis:FAUST
DBC-sag: 48280

Dette for afklare mulighederne for
> Men for brønd 3.5-4.3 er dette ikke muligt. Påhængsposter/lokale poster har 775100-katalog og basisposterne har 870970-basis som prefix.
> Hvis jeg antager at vi kan få indekset fra note84, pkt 2 så kan prefix sættes til 775100-katalog og vi kan altid få et hit (men når det er en basispost dog et andet id)

Det vil dog stadig kun være ét skridt på vejen til 4.3

#89 Updated by Rolf Madsen almost 3 years ago

  • Target version changed from DDB CMS 2017 1. opgradering (7.x-4.0.2) to DDB CMS 2017 1. opgradering (DBC sprintbacklog)

#90 Updated by Steen Larsen almost 3 years ago

_DBC info for FBS biblioteker 25.11.2016
Af hensyn til ændringer i driftsafvikling af indeksering på Brønd 3.5, nedlægges OpenSearch version 4.1 og 4.1.1.
Ifølge vores optegnelser er der ingen FBS biblioteker, der anvender de to nævnte versioner.
Versionerne nedlægges mandag morgen den 28.11.16 kl. 9.00.
http://opensearch.addi.dk/b3.5_4.2/
http://opensearch.addi.dk/b3.5_4.3/
Bemærk, at ovenstående ikke medfører ændringer på de biblioteker, der anvender Brønd 3.0 (ikke FBS)._

Hmm, underligt - for ddbcms er ikke klar til version 4.2 så det burde fejle for nogle poster

#91 Updated by Steen Larsen almost 3 years ago

Hmm, det ser ud til udfordringen med skift fra 4.0.1 til 4.3 hele tiden har været der for FBS, jvf sagerne #1270 og #1677

Måske en generel løsning skulle afhænge lidt af hvad man starter med

1)
Når man har ét faustnummer uden namespace (f.eks. fra lånerstatus) så laves denne søgning: "rec.id=870970:FAUST or rec.id=775100:FAUST"
Resultatet bestemmer hvilket pid der benyttes til posten i visningen/link (dvs om det er 870970:FAUST eller 775100:FAUST der skal bruges)
Vær opmærksom på at der her altså ikke gættes på namespace via centrale og lokale faustnumre.
Dette burde gælde for brønd 3.0 og brønd 3.5

2)
Har man istedet et pid, dvs namespace:id (f.eks. fra urlen) søges på sædvanlig vis: "rec.id=namespace:id"
Hvis der er et resultat/en post benyttes pid fra denne post.
Bemærk at alle kilder (bibliotekskatalog, ereolen, filmstriben, artikler m.m.) er inkluderet her

3)
Hvis der ikke er et resultat i 2) og namespace er 870970 eller 775100 så udtrækkes id (=faust) og søgning som i 1) gennemløbes for se om der skulle være gevinst alligevel.

Jeg har foreslået 2+3 for at håndtere det store skifte mellem 4.0.1 og 4.2 hvor mange af pid'erne skifter (fra 870970-basis til 775100-katalog)
Man skulle jo gerne hvis man finder et id lave viderestilling til den korrekte pid, men er det muligt på det trin i processen?

Dog kan vi ikke håndtere skiftet til FBS hvor alle 900-numre plus nogle flere skifter id.
Kunne ellers være smart hvis det gamle id var gemt i et indeks og opensearch kunne søge den rigtige post frem.

Er man ligeglad med gamle urler/gammelt indhold kan 2+3 jo gøres noget simplere.

#92 Updated by Gitte Barlach almost 3 years ago

  • Status changed from 8 to Closed

Videreføres i andre sager.

Sagen er opsummeret i #1698#note-91:

Punkt 1) - faust fra lånerstatus - løses i sag #2048

Punkt 2) - håndtering af gamle urler/pid - behandles i sag der oprettes senere

#93 Updated by Steen Larsen almost 3 years ago

Vedr punkt 2 i #1698#note-92 - se #2071

#94 Updated by Rolf Madsen almost 3 years ago

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

#95 Updated by Rolf Madsen almost 3 years ago

  • Related to Bug #2071: Håndtering af pid ved skift af opensearch added

Also available in: Atom PDF