---- 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
Is anyone working on this?
(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.
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
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.
> ◊ 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.
(In reply to Katrin Fischer from comment #5) > I think we can do this now via cronjob I have added Bug 14469 for this.
As Marcel pointed out on the other bug, I guess this was some kind of misunderstanding. We already can, I thought we could…
Ah sorry, what I meant is that there is no way from the GUI - but the cronjob probably does the job well enough :)
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.
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/
(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.