Project

General

Profile

Bug #1626

Ding viser stadig materialer slettet fra brønden

Added by Thomas Hansen over 3 years ago. Updated 11 months ago.

Status:
Needs analysis
Priority:
High
Assignee:
Target version:
Estimated time:
URL med eksempel:
Kategorier:
Søgning - Materialevisning

Description

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, 04/15/2016 01:56 PM

Related issues

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

History

#2 Updated by Steen Larsen over 3 years ago

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 Updated by Thomas Hansen over 3 years ago

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 Updated by Steen Larsen over 3 years ago

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 Updated by Steen Larsen over 3 years ago

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

#6 Updated by Rolf Madsen over 3 years ago

  • Status changed from New to DBC (waiting)
  • Target version set to DDB CMS - Analyse og prioritering udestår

#7 Updated by Thomas Hansen over 3 years ago

Well, det skal vel også fungere for 4.0.1?

#8 Updated by Steen Larsen over 3 years ago

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 Updated by Thomas Hansen about 3 years ago

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

Og hvad returnerer 4.0.1?

#10 Updated by Simon Holt about 3 years ago

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

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

#11 Updated by Thomas Hansen about 3 years ago

Nej, entitycache bliver ikke brugt for ting objekter.

#12 Updated by Steen Larsen about 3 years ago

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 Updated by Thomas Hansen about 3 years ago

Så burde min PR jo fungere.

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

#14 Updated by Rolf Madsen about 3 years ago

#15 Updated by Rolf Madsen about 3 years ago

  • Status changed from DBC (waiting) to 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 Updated by Thomas Hansen about 3 years ago

Uhm, hvad precis er rettet?

#17 Updated by Steen Larsen about 3 years ago

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 Updated by Rolf Madsen about 3 years ago

  • Status changed from Technical test to DBC (waiting)

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

#19 Updated by Thomas Hansen about 3 years ago

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 Updated by Steen Larsen about 3 years ago

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 Updated by Rolf Madsen about 3 years ago

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 Updated by Steen Larsen about 3 years ago

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 Updated by Steen Larsen about 3 years ago

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 Updated by Rolf Madsen almost 3 years ago

  • Related to Bug #483: Ikke-eksisterende objekter vises ikke korrekt added

#25 Updated by Thomas Hansen over 2 years ago

  • Kategorier Søgning - Materialevisning added

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

#26 Updated by Steen Larsen over 2 years ago

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

#27 Updated by Rolf Madsen over 2 years ago

  • Target version changed from DDB CMS - Analyse og prioritering udestår to Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1)

#28 Updated by Rolf Madsen about 2 years ago

  • Status changed from DBC (waiting) to Need more info

#29 Updated by Rolf Madsen about 2 years ago

  • Status changed from Need more info to 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 Updated by Thomas Hansen over 1 year ago

  • Description updated (diff)
  • Status changed from Closed to 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 Updated by Rolf Madsen over 1 year ago

  • Status changed from New to Needs analysis
  • Target version changed from Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1) to Release 29-2 - Bugfixes (7.x-4.5.0)

#32 Updated by Michael W. Christoffersen over 1 year ago

  • Assignee set to 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 Updated by Rolf Madsen over 1 year ago

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 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Rolf Madsen to 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 Updated by Rolf Madsen over 1 year ago

  • Is duplicate of Bug #1739: Se alle eksemplarer for sletteposter added

#37 Updated by Rolf Madsen over 1 year ago

  • Assignee changed from Thomas Hansen to Steen Larsen
  • Target version changed from Release 29-2 - Bugfixes (7.x-4.5.0) to Release 29-2 - Bugfixes (Needs analysis)

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

#38 Updated by Rolf Madsen about 1 year ago

  • Target version changed from Release 29-2 - Bugfixes (Needs analysis) to Release 33 - Bugfixes

#39 Updated by Simon Holt 11 months ago

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 Updated by Rolf Madsen 11 months ago

  • Related to Bug #2223: Cashingstrategi (tidl. Værkmatch har hukommelse (#3162 skal merges sammen med dette issue)) added

#41 Updated by Rolf Madsen 11 months ago

  • Priority changed from Normal to High

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

Also available in: Atom PDF