Bug 3069 - Add configuration to deactivate auto-updating the reservoir via Z39.50
Summary: Add configuration to deactivate auto-updating the reservoir via Z39.50
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement with 6 votes (vote)
Assignee: Galen Charlton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-28 09:43 UTC by Frédéric Demians
Modified: 2023-10-07 20:14 UTC (History)
9 users (show)

See Also:
Change sponsored?: Seeking cosponsors
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:06:02 UTC


---- Reported by frederic@tamil.fr 2009-03-28 09:43:08 ----

Koha Z39.50 client process isn't easy to understand from a end-user
perspective.

Current process:

  ◊ In cataloguing, a search to multiple z3950 target is sent.
  ◊ Result is displayed. 20 first results are displayed for each target.
  ◊ Each record is stored in import_* tables for further usage via
    'reservoir'.
  ◊ By clicking on Import, one record is copied in data entry page.
  ◊ Cataloger can modify biblio record, localized it, etc.
  ◊ In next cataloguing operation, a search will be done both in
    catalog and reservoir (import_biblios table), and will retrieve
    eventually biblio records from previous z3950 searches.

Some design choices are disputable:

  ◊ Why just 20 records per host are displayed?
  ◊ Why all retrieved records are stored in reservoir? People generally
    don't understand that. Why 20 and not 5 or 100 records?
  ◊ Search in reservoir is done with BreedingSearch function only in
    'title' and 'isbn' fields. So it's impossible to retrieve a biblio
    record by author.
  ◊ There is no user interface allowing to see what's going on with
    biblio records stored in reservoir and coming from z3950 searches.
    There is such an interface for staged records: those imported
    explicitly into reservoir from files (in Tools).
  ◊ So if a library uses to do search in 4 z3950 hosts, each search may
    add 4 x 20 = 60 records in import_biblios and import_records
    tables. The number of records added this way will grow indefinitely
    without any mean to clean reservoir.
 
Some ideas of improvement:

  ◊ Add a syspref 'ReservoirZ3950' which when at false disable biblio
    records adding from z3950 searches.
  ◊ Add an UI in Tools to see the number of biblio records in reservoir
    added from z3950 searches.
  ◊ Add a 'clear' option in Tool to delete all records in reservoir
    coming from z3950, and eventually also coming from file imports.



---- Additional Comments From mjr@ttllp.co.uk 2009-03-29 14:47:41 ----

I'd support all three improvements.  Also, I'd like to be able to clear z3950 results from only one server: sometimes we try a server and it's just not useful for that library, returning junky results.




--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:06 UTC  ---

This bug was previously known as _bug_ 3069 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3069

Actual time not defined. Setting to 0.0
CC member mjr@ttllp.co.uk does not have an account here

Comment 1 Tomás Cohen Arazi 2011-02-23 13:41:51 UTC
Is anyone working on this?
Comment 2 Viktor Sarge 2011-06-07 11:06:14 UTC
(In reply to comment #1)
> Is anyone working on this?

I have no idea but for what it´s worth I've noticed that this behaviour is bugging people.
Comment 3 Viktor Sarge 2011-06-07 11:15:07 UTC
Hm, I can´t seem to replicate the problem with biblios filling up in 3.4.1, but it seems to be there in 3.4.0. Still there are things to be done here even if biblios filling up (may) have been resolved in 3.4.1
Comment 4 Gaetan Boisson 2012-03-06 13:07:15 UTC
I am reviving this bug. The problem is still there in master as of today from what i have seen.

We still get 20 results from a z39.50 search, with no control over this limit.

There is no way to clean the reservoir from the biblio which have been imported through z39.50, like there is a way to do it for biblios imported via the import tools.

It does seem like the search on author is still not possible, but i'm not 100% positive about it.
Comment 5 Katrin Fischer 2015-05-25 08:01:22 UTC
>  ◊ Add a syspref 'ReservoirZ3950' which when at false disable biblio
>    records adding from z3950 searches.

Still valid.

>  ◊ Add an UI in Tools to see the number of biblio records in reservoir
>    added from z3950 searches.

Still valid.

>  ◊ Add a 'clear' option in Tool to delete all records in reservoir
>    coming from z3950, and eventually also coming from file imports.

I think we can do this now via cronjob - not quite the same, but should be helpful. Also, you can 'clean' batches.

I think it might be good to split this up into several bugs for the remaining issues.
Comment 6 Mirko Tietgen 2015-06-28 10:07:03 UTC
(In reply to Katrin Fischer from comment #5)

> I think we can do this now via cronjob

I have added Bug 14469 for this.
Comment 7 Mirko Tietgen 2015-06-28 12:55:54 UTC
As Marcel pointed out on the other bug, I guess this was some kind of misunderstanding. We already can, I thought we could…
Comment 8 Katrin Fischer 2015-06-28 13:30:14 UTC
Ah sorry, what I meant is that there is no way from the GUI - but the cronjob probably does the job well enough :)
Comment 9 Dave J 2017-03-31 09:30:23 UTC
Folks,

We have nearly 2000 books loaded in our Koha system now, but over 12000 reservoir records. I note that there is a mention of a cron job to clear these... can you let me know how to run it, please, as it's obviously not running. We are using version 16.11.03 I can't find any information on this anywhere in either the manual or the internet, just this Bugzilla report.

Thanks for your help.
Comment 10 Owen Leonard 2017-04-07 12:23:30 UTC
Dave J, this issue sounds more like a support request than a bug report. 

Support requests can be made on the Koha mailing list, on IRC, or by contracting with a support vendor. All these options are linked to here: https://koha-community.org//support/
Comment 11 Katrin Fischer 2019-05-04 19:38:05 UTC
(In reply to Owen Leonard from comment #10)
> Dave J, this issue sounds more like a support request than a bug report. 
> 
> Support requests can be made on the Koha mailing list, on IRC, or by
> contracting with a support vendor. All these options are linked to here:
> https://koha-community.org//support/

It's an option of the cleanup_database.pl cronjob.

Updating title slightly to make connection to the reservoir which I think is the main issue here.