Projekt

Generelt

Profil

Bug #1626

Ding viser stadig materialer slettet fra brønden

Tilføjet af Thomas Hansen for cirka 3 år siden. Opdateret for 8 måneder siden.

Status:
Needs analysis
Prioritet:
High
Tildelt til:
Anslået tid:
URL med eksempel:
Kategorier:
Søgning - Materialevisning

Beskrivelse

Hvis nogen har kigget på et materiale, og det efterfølgende er slettet fra brønden, så vil man stadig kunne se materiale siden da ding ikke checker om materialet eksisterer i brønden når den loader det lokale proxy objekt.

Det er nok ikke blevet opdaget fordi at slettede materialer af gode grunde ikke vil dukke op i søgeresultater.

Men da loaderen i forvejen sætter svaret fra brønden på objektet (evt en korttidscached version) så er det ikke så svært lige at checke om brønden kender materialet.

PR følger.

tompost.png (22 KB) tompost.png Steen Larsen, 15.04.2016 13:56

Relaterede sager

relaterer til DDB CMS - Bug #483: Ikke-eksisterende objekter vises ikke korrektClosed
relaterer til DDB CMS - Bug #2223: Cashingstrategi (tidl. Værkmatch har hukommelse (#3162 skal merges sammen med dette issue))Resolved (tag version)
duplikater DDB CMS - Bug #1739: Se alle eksemplarer for sletteposterResolved (tag version)
følger DDB CMS - Enhancement #1577: Skift til opensearch 4.2Closed

Historik

#2 Opdateret af Steen Larsen for cirka 3 år siden

Er den relateret til #483 ?

Sletteposter kan ganske rigtigt ikke (mere) søges frem men slås op via getobject kan de jo fint.
Problemet er dog at man stadigvæk ikke kan stole på recordStatus (fra getobject) - den kan være active selvom posten ikke findes i vores beholdning. Det er dog rigtigt at hvis posten er et udgået faustnummer o.lign så vises recordStatus=delete

#3 Opdateret af Thomas Hansen for cirka 3 år siden

Joe, den er relateret.

Jeg har gravet i det, og så vidt jeg kan se ender den med at kalde getObject.

Men at getObject kan finde på at returnere et objekt selvom det er slettet er lidt en streg i regningen...

Jeg skal lige grave lidt dybere, for det ser også ud til at ding er ret dårlig til at håndtere hvis brønden siger at IDet ikke eksisterer.

#4 Opdateret af Steen Larsen for cirka 3 år siden

Jeg tror lige du skal vente lidt.

Jeg har lige kigget tilbage i den gamle dbc-sag (nævnt i 483) og i svaret blev opensearch 4.1 nævnt.
Da vi - stadigvæk - kører med 4.0.1 skal jeg lige have bekræftet hvad der faktisk returneres mht recordstatus for version 4.2 (jeg kan ikke huske hvilken version jeg undersøgte i går)

Hvis der stadig er underligheder opretter jeg en dbc-sag for at få afklaret hvordan det er i dag mht getobject og recordstatus.

#5 Opdateret af Steen Larsen for cirka 3 år siden

Opensearch 4.2 giver samme resultater så jeg har spurgt om status på recordstatus - DBC sag 32467

#6 Opdateret af Rolf Madsen for cirka 3 år siden

  • Status ændret fra New til DBC (waiting)
  • Udgave sat til DDB CMS - Analyse og prioritering udestår

#7 Opdateret af Thomas Hansen for cirka 3 år siden

Well, det skal vel også fungere for 4.0.1?

#8 Opdateret af Steen Larsen for cirka 3 år siden

Det viser sig at der faktisk er en forskel på opensearch 4.0.1 og 4.2.
Når man søger og får posterne tilbage er der forskel på identifier - her med aakb's agency:

4.2:
775100-katalog:26558433
870970-basis:26558433

4.0.1
870970-basis:22016407
870970-basis:22016407

Det er feltet identifier der benyttes i urlerne

Hvis posten ovenfor med id'et 775100-katalog:26558433 bliver slettet så vil ting-object-urlen pege på en "tom" post.

Eksempel med en reel post der er slettet, 775100-katalog:00150568 - her returneres


1
1

Error: unknown/missing/inaccessible record: 775100-katalog:00150568
775100-katalog:00150568

Og overfor brugerne vises en huskeliste-knap og ikke andet. Kan ses her: https://vanilla-alma.ddbcms.dk/ting/object/775100-katalog:00150568
Det løser ikke problemet med eksisterende urler (i google) der peger på 4.0.1-versionen. Disse vil stadig slås op med getobject.

Jeg kan ikke gennemskue om denne ændring har betydning andre steder - Jeg opdaterer sag #1577 (vedr skiftet til 4.2)

#9 Opdateret af Thomas Hansen for næsten 3 år siden

Er det 4.2 der returnerer "Error: unknown/missing/inaccessible record: 775100-katalog:00150568"?

Og hvad returnerer 4.0.1?

#10 Opdateret af Simon Holt for næsten 3 år siden

Hvad med EntityCache. Bliver den brugt på ting objects?

Hvis ja, hvornår bliver den egentlig clearet så?

#11 Opdateret af Thomas Hansen for næsten 3 år siden

Nej, entitycache bliver ikke brugt for ting objekter.

#12 Opdateret af Steen Larsen for næsten 3 år siden

Vi skifter jo nok til 4.2 på et tidspunkt (#1577) så jeg ved ikke om vi skal udvikle noget til 4.0.1

Det er identifier som "styrer" om "unknown/missing/inaccessible record" returneres og det er det samme for 4.0.1. og 4.2.

Lad givet at posten med faustnummer 00150568 er slettet i vores bibliotek (775100)
Opensearchs getObject:

Opslag på 775100-katalog:00150568 giver "unknown/missing/inaccessible record"
Opslag på 870970-basis:22016407 giver posten med indhold.

Jeg havde en forestilling om at når man henter 870970-basis:22016407 så kunne feltet recordStatus afspejle om posten er tilgængelig for det konkrete bibliotek (opensearch-profil) eller ikke. Det ville dog kræve ændring i opensearch og i ddbcms og det ved jeg ikke om vi skal forsøge.

Vi har indtil nu levet med at opslag på poster (som vi ikke har) viser indholdet, men uden reserver-knap eller beholdningsoplysninger så det kan vi selvfølgelig fortsætte med.
Svaret med "unknown/missing/inaccessible record" hvor der intet indhold er overhovedet bør dog håndteres - f.eks. med en fejl404-side eller lignende

#13 Opdateret af Thomas Hansen for næsten 3 år siden

Så burde min PR jo fungere.

Prøver lige at få et slettet materiale at teste med.

#14 Opdateret af Rolf Madsen for næsten 3 år siden

#15 Opdateret af Rolf Madsen for næsten 3 år siden

  • Status ændret fra DBC (waiting) til Technical test

Svar fra DBC 16. marts 2016:
Det bør være rettet i Open search 4.2
Stig undersøger om der er svaret på spørgsmålet omkring status på recordstatus
DBC er i dialog med Steen Gert Larsen. Sagen er stadig i proces.

NB. opensearch 4.2 er blevet testet og der er fundet enkelte fejl i den open search version der benyttes til FBS bibliotekerne, som vi har bedt DBC udbedre. Derudover har Martin Cording oplyst at der bliver smidt nogle fejl i loggen ved søgninger mod opensearch 4.2, som vi får afklaret i det kommende DDB CMS udviklingssprint hos DBC.

#16 Opdateret af Thomas Hansen for næsten 3 år siden

Uhm, hvad precis er rettet?

#17 Opdateret af Steen Larsen for næsten 3 år siden

Sandsynligvis ikke mere end det jeg allerede har beskrevet i note-8 og note-12?

Det ser ud til at opensearch 4.2 har en feature med "objectsAvailable" i response som jeg afventer svar på fra dbc

#18 Opdateret af Rolf Madsen for næsten 3 år siden

  • Status ændret fra Technical test til DBC (waiting)

Det lyder som om mit statusskifte til technical test var lige friskt nok ...

#19 Opdateret af Thomas Hansen for næsten 3 år siden

Jeg er bare forvirret og kan ikke følge med.

Men jeg har testet et materiale der skulle være slettet på eReolen i 4.0.1, og det dukker ikke op i søgninger, men getObject giver mig ikke mange antydninger af at det er slettet.

Jeg kan ikke teste i højere versioner da jeg ikke kan finde ud af at authentificere.

#20 Opdateret af Steen Larsen for næsten 3 år siden

Lad os lige vente på afklaringen med 4.2 (4.0.1 kan ikke bruges til noget i denne sammenhæng).

Mht authentificering kender jeg kun IP-authentificeringen hvor DBC har lukket op for vores ip og denne er afhængig af opensearch-versionen (sic!).

#21 Opdateret af Rolf Madsen for næsten 3 år siden

Har I ikke adgang til http://opensearch.addi.dk/b3.0_4.2/ eller er den ikke tilstrækkelig?

Ellers stik mig søgningen så kan jeg køre den.

#22 Opdateret af Steen Larsen for næsten 3 år siden

Jeg har fået svar fra DBC - vi har en mulighed for at teste om en given post er tilgængelig eller ikke

_Et værk består af en til flere klynger. En klynge (internt kaldes de units) består af en til flere poster, som alle er matchet til at være samme bibliografiske enhed.
Fra klyngen vælges den højst prioriterede post (hvert agency har en vis-prioriteringsliste), hvis pid man kan se i
indeholder de aktive pid'er i klyngen der er tilgængelige med den valgte søgeprofil, sorteret efter agency'ets prioriteringsliste.
blev introduceret for få information tilbage om "underliggende" poster aht til det kommende nye netpunkt.dk, men kan indlysnede også bruges til det du beskriver.
active/deleted findes for hver enkelt post i en klynge, ikke kun for 870970-posten.
_

Med et konkret eksempel (post med faust 00150568 har vi ikke - men vi har 25360451) - kig selv efter feltet objectsAvailable

<getObjectRequest>
<agency>775100</agency>
<profile>bibkat</profile>
<identifier>870970-basis:00150568</identifier>  
<identifier>775100-katalog:00150568</identifier> 
<identifier>870970-basis:25360451</identifier>
<identifier>775100-katalog:25360451</identifier>   
</getObjectRequest>

som giver dette svar i opensearch b3.0_4.2 (jeg har fjernet det meste af dkabm)


<searchResponse>
   <result>
      <hitCount>4</hitCount>
      <collectionCount>4</collectionCount>
      <more>false</more>
      <searchResult>
         <collection>
            <resultPosition>1</resultPosition>
            <numberOfObjects>1</numberOfObjects>
            <object>
               <dkabm:record>
                  <ac:identifier>00150568|870970</ac:identifier>
                  ...
               </dkabm:record>
               <identifier>870970-basis:00150568</identifier>
               <primaryObjectIdentifier>870970-basis:00150568</primaryObjectIdentifier>
               <recordStatus>active</recordStatus>
               <creationDate>2005-03-01</creationDate>
               <objectsAvailable/>
            </object>
         </collection>
      </searchResult>
      <searchResult>
         <collection>
            <resultPosition>2</resultPosition>
            <numberOfObjects>1</numberOfObjects>
            <object>
               <error>Error: unknown/missing/inaccessible record: 775100-katalog:00150568</error>
               <identifier>775100-katalog:00150568</identifier>
            </object>
         </collection>
      </searchResult>
      <searchResult>
         <collection>
            <resultPosition>3</resultPosition>
            <numberOfObjects>1</numberOfObjects>
            <object>
               <dkabm:record>
                  <ac:identifier>25360451|870970</ac:identifier>
                  ...
               </dkabm:record>
               <identifier>870970-basis:25360451</identifier>
               <primaryObjectIdentifier>870970-basis:25360451</primaryObjectIdentifier>
               <recordStatus>active</recordStatus>
               <creationDate>2005-03-02</creationDate>
               <objectsAvailable>
                  <identifier>775100-katalog:25360451</identifier>
               </objectsAvailable>
            </object>
         </collection>
      </searchResult>
      <searchResult>
         <collection>
            <resultPosition>4</resultPosition>
            <numberOfObjects>1</numberOfObjects>
            <object>
               <dkabm:record>
                  <ac:identifier>25360451|870970</ac:identifier>
                  ...
               </dkabm:record>
               <identifier>775100-katalog:25360451</identifier>
               <primaryObjectIdentifier>870970-basis:25360451</primaryObjectIdentifier>
               <recordStatus>active</recordStatus>
               <objectsAvailable>
                  <identifier>775100-katalog:25360451</identifier>
               </objectsAvailable>
            </object>
         </collection>
      </searchResult>
      <facetResult/>
   </result>
</searchResponse>

Mit problem er så at den profil vi benytter i produktion ("opac") ikke viser ovenstående funktionalitet så det er vist den uendelige historie.
Jeg undersøger videre... (det er for iøvrigt dbc sag nr 32467)

#23 Opdateret af Steen Larsen for næsten 3 år siden

Det er tilsyneladende ingen fejl at systemet gør som beskrevet i tidligere note.
Så derfor kan jeg ikke se at vi effektivt kan afgøre om en post er tilgængelig eller ikke.

Gentagelse af eksemplet ovenfor med den problematiske post:

Vi har ikke 00150568 så opslag på 870970-basis:00150568 giver dette:

<object>
   <dkabm:record>
      <ac:identifier>00150568|870970</ac:identifier>
      <ac:source>Bibliotekskatalog</ac:source>
      ...
   </dkabm:record>
   <identifier>870970-basis:00150568</identifier>
   <primaryObjectIdentifier>870970-basis:00150568</primaryObjectIdentifier>
   <recordStatus>active</recordStatus>
   <creationDate>2005-03-01</creationDate>
   <objectsAvailable>
      <identifier>870970-basis:00150568</identifier>
   </objectsAvailable>
</object>

Er det effektivt at for Bibliotekskatalog-poster at checke om LIBNO-katalog:XXX findes i listen af objectsAvailable når man søger efter 870970-basis:XXX.
Og i det hele taget umagen værd? Jeg tror det ikke.

Posten hvor fejlkoden returneres skal selvfølgelig håndteres på passende vis - se vedlagte
Error: unknown/missing/inaccessible record: 775100-katalog:00150568 returneres.

#24 Opdateret af Rolf Madsen for mere end 2 år siden

  • relaterer til Bug #483: Ikke-eksisterende objekter vises ikke korrekt tilføjet

#25 Opdateret af Thomas Hansen for mere end 2 år siden

  • Kategorier Søgning - Materialevisning tilføjet

@steen
Well det hjælper ikke eReolen, da den bruger basis records. getObject kalder stadig slettede materialer for aktive.

#26 Opdateret af Steen Larsen for mere end 2 år siden

Gad vide om opensearch 4.4 (der er nævnt i #1849#note-17) kan klare det problem?

#27 Opdateret af Rolf Madsen for mere end 2 år siden

  • Udgave ændret fra DDB CMS - Analyse og prioritering udestår til Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1)

#28 Opdateret af Rolf Madsen for næsten 2 år siden

  • Status ændret fra DBC (waiting) til Need more info

#29 Opdateret af Rolf Madsen for næsten 2 år siden

  • Status ændret fra Need more info til Closed

Jeg antager at opensearch 4.5 vil løse problemstillingen omkring getObject der behandler slettede materialer som aktive.

Jeg har bedt DBC bekræfte at det er tilfældet.

Hvis der ikke er yderligere protester vil jeg lukke dette issue, med tak for det dybe gravearbejde!

#30 Opdateret af Thomas Hansen for cirka et år siden

  • Beskrivelse updated (diff)
  • Status ændret fra Closed til New

Desværre Rolf. eReolen bruger https://opensearch.addi.dk/b3.5_4.5/

Her har vi et materiale der er slettet: https://ereolen.dk/ting/object/870970-basis%3A29313512

 

#31 Opdateret af Rolf Madsen for cirka et år siden

  • Status ændret fra New til Needs analysis
  • Udgave ændret fra Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1) til Release 29-2 - Bugfixes (7.x-4.5.0)

#32 Opdateret af Michael W. Christoffersen for cirka et år siden

  • Tildelt til sat til Rolf Madsen

Er der nogen der har overblik over løsning og overlap mellem disse fire issues:

#483 Closed

#1577 Closed

#1626 Needs analysis

#1739 Resolved (tag version)

#33 Opdateret af Rolf Madsen for cirka et år siden

Opslag i https://opensearch.addi.dk/b3.5_4.5/ og https://opensearch.addi.dk/b3.5_5.0/ giver samme resultat.

Request

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://oss.dbc.dk/ns/opensearch">
  <SOAP-ENV:Body>
    <ns1:getObjectRequest>
      <ns1:agency>100200</ns1:agency>
      <ns1:profile>test</ns1:profile>
      <ns1:identifier>870970-basis%3A29313512</ns1:identifier>
      <ns1:objectFormat>dkabm</ns1:objectFormat>
    </ns1:getObjectRequest>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Response

<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns="http://oss.dbc.dk/ns/opensearch">
    <SOAP-ENV:Body>
        <searchResponse>
            <result>
                <hitCount>1</hitCount>
                <collectionCount>1</collectionCount>
                <more>false</more>
                <searchResult>
                    <collection>
                        <resultPosition>1</resultPosition>
                        <numberOfObjects>1</numberOfObjects>
                        <object>
                            <error>

Error: unknown/missing/inaccessible record: 870970-basis%3A29313512

</error>
                            <identifier>870970-basis%3A29313512</identifier>
                        </object>
                    </collection>
                </searchResult>
                <facetResult/>
                <statInfo>
                    <fedoraRecordsCached>0</fedoraRecordsCached>
                    <fedoraRecordsRead>0</fedoraRecordsRead>
                    <time>0.26294</time>
                    <trackingId>os:2018-02-19T11:41:26:886132:6755</trackingId>
                </statInfo>
            </result>
        </searchResponse>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

#35 Opdateret af Rolf Madsen for cirka et år siden

  • Tildelt til ændret fra Rolf Madsen til Thomas Hansen

Er det ikke korrekt at recordStatus ikke vises hvis man ser på Opensearch dokumentationen?

https://opensource.dbc.dk/services/open-search-web-service

Parameters: Always present Repeatable Sub element of Description

recordStatus

if object is present

no

object

The status of the returned record. Possible values: active, delete.

#36 Opdateret af Rolf Madsen for cirka et år siden

  • duplikater Bug #1739: Se alle eksemplarer for sletteposter tilføjet

#37 Opdateret af Rolf Madsen for cirka et år siden

  • Tildelt til ændret fra Thomas Hansen til Steen Larsen
  • Udgave ændret fra Release 29-2 - Bugfixes (7.x-4.5.0) til Release 29-2 - Bugfixes (Needs analysis)

Aarhus vil undersøge om dette issue faktisk er blevet løst i #1739.

#38 Opdateret af Rolf Madsen for 9 måneder siden

  • Udgave ændret fra Release 29-2 - Bugfixes (Needs analysis) til Release 33 - Bugfixes

#39 Opdateret af Simon Holt for 8 måneder siden

Når #2223 bliver merget kommer det til at påvirke løsningen her og problemet i #1739.

Vi går fra at bruge en søgning med holdingsitem.agencyid filter til at bruge getObject request, der nu kan hente flere poster ad gangen, når vi viser en post. Så før, hvor poster biblioteket ikke længere har beholdning på, ville blive filtreret fra i søgningen med agencyid filteret, vil de nu blive returneret. Så vi vil nok se poster med den underlige tommme beholdning igen og 0 sek ventetid (som nævnt af Steen her i sagen: https://platform.dandigbib.org/issues/1739#note-12).

I #1460 går vi fra at man skal indstille hvilke poster, der skal have en reserveringsknap under /admin/config/ting/reservable, til at det er svaret fra FBS der afgør om posten skal have en reserveringsknap. Det løser en række af problemer. Og da man i Cicero i forvejen kan bestemme hvad der skal reserveres (her helt ned på materiale plan), er der jo ingen grund til at man også skal gøre det i DDB CMS.

Måske kunne man lave noget lignende beholdning. På samme vis som ved reserveringer, skal man også under /admin/config/ting/holdings angive hvilke poster der skal vise beholdning. Så ville vi sikre, at der ikke bliver vist en tom beholdning på nogle poster, da det ikke længere er DDB CMS der skal afgøre om det skal vises, men FBS som også må vide bedst.

#40 Opdateret af Rolf Madsen for 8 måneder siden

  • relaterer til Bug #2223: Cashingstrategi (tidl. Værkmatch har hukommelse (#3162 skal merges sammen med dette issue)) tilføjet

#41 Opdateret af Rolf Madsen for 8 måneder siden

  • Prioritet ændret fra Normal til High

Dette issue skal tænkes ind under review af #2223.

Eksporter til Atom PDF