[Koha-devel] DOM, id:x, reindexing (bug8665?)

[Archives and Collections Society]

Dear Jared,

Many thanks for the reply. Comments|questions interspersed below:

At 04:22 PM 10/17/2012 -0400, Jared Camins-Esakov wrote:
>Our cataloguers are doing a sterling job ridding our db of duplicate 001 
>fields, but every time they do a simple edit of *only* the 001, both OPAC 
>and staff-admin page find TWO absolutely identical (biblio, barcode, etc) 
>records.
>
>Zebra incremental (-z) counts the *edit* as a completely new record.
>
>I can get rid of it by doing a full zebra reindex (-a and -b). This 
>"error" is totally reprodicible in our db. Can anyone elso confirm it 
>please? (edit a 001 tag, save, wait for the CRON -z, and search on title.)
>
>This is the way Zebra works.

I understand that -- however (purely based on personal experience after 
only two years of use) the "concept" of Koha is that the CRON takes care of 
updating the search engine after cataloguers' edits (and I don't think that 
even a reboot does a "complete" re-cataloguing job.)

For example, if I edit the date of publication in a biblio, zebra finds the 
edit, makes the change within sixty seconds (our CRON starts '*/1') and 
does not create a second biblio. But if I edit (again in a biblio) the 001, 
we get an entirely identical, but supplemental and erroneous record that 
"sticks."

I've got more than enough computing power to CRON a complete reindex every 
minute, and if that was all that was necessary to fix everything I can do 
it very easily -- but should this go into the users' manual? I fear that 
other users may not have an 8-core I7 with raided ssd's and 16Gb ram. Nor 
do I think it fixes all the problems. Continued below...

>A serious addition to this, is that we seem to have totally lost search 
>capability on serials. Â Example: we have a series of 40 "Warship 
>Profiles" which a mysql query (the one I gave under bug 8665) gives me:
>
>biblionumbers:
>17472, 17473, 17474, 17475, 17476, 17477, 17478, 17479, 17480, 17482, 
>17483, 17484, 17485, 17486, 17487, 17488, 17489, 17493, 17494, 17495, 
>17496, 17497, 17498, 17499, 17500, 17501, 17502, 17503, 17504, 17505, 
>17506, 17508, 17509, 17511, 17513, 17514, 17516, 17517, 17518, 17520
>
>id (Control Number 001): Â 01032053
>
>but NONE of the records can be found -- not by biblionumber, nor by 
>control-number, nor by barcode, nor by title, author, etc ... Â The 
>records are there (other mysql queries give me the barcodes, values, 
>shelving locations, titles, authors, etc) but as far as staff and our 
>patrons are concerned, they plain don't exist. Only for a mysql query.
>
>
>Isn't this the problem you were trying to solve to begin with? You can 
>access those records directly, as an aside: just go to 
>/cgi-bin/koha/catalogue/<http://detail.pl?biblionumber=XXXX>detail.pl?biblionumber=XXXX 
>

Yes -- it is one of the "problem[s] you were trying to solve to begin with" 
... a "normal" search: 
http://koha-admin/cgi-bin/koha/catalogue/search.pl?q=biblionumber=17472 
comes up with "No results match your search for 'biblionumber=17472' in NMA 
Catalog."

>(easiest is to just view another record, then change the biblionumber in 
>the URL).

Many thanks - from a quick try that works - is there a way in staff-admin 
to directly use 'detail.pl'? (how I explain that to our lady cataloguers 
downstairs is going to be challenging, and it remains to be seen if 
changing biblionumber or 001 will get these records back into the OPAC.)

>>[snip] There must have been a good reason, hence our efforts to normalize 
>>001 to be a unique identifier.
>No, this was a bug. There is a patch to restore biblionumber as the z:id.

Please (and I'm not trying to be obtuse), how do I install the patch to our 
production box?  That's exactly my next question:

>Chris C. has a comment in Bug 8665 "Use a user-specified field for z:id." 
>Â I am no expert with zebra (and so far haven't worked out the role or the 
>wheareabouts of id:x), but: Â If z:id is currently set to '001', how do I 
>set it to biblionumber in 3.8.5?
>
>Perhaps this will help our non-existent "authorities"?
>
>There's another bug, also patched, related to this. It has to do with 
>extra spaces in a configuration file.

Again, desperately trying to be diplomatic and not annoy you, how do I get 
the patch into production.

I made a huge mistake (me, personally, and I take all the blame) when I 
upgraded from 3.6.1 to 3.8.x without enough testing at our end. Now I'm 
between the devil and the deep blue sea; go back to 3.6.1 and discard two 
months of cataloguing (maybe try to export these - now over a thousand - 
biblios from 3.8.5 and re-import them in 3.6.1?) or patch 3.8.5?

I remain relatively confident that the mysql is retaining the data and that 
it's 'only' a zebra problem. So it's patching 3.8.5 that I'd prefer. As I 
said below, I'll put time and effort into it, and share the results with 
this community.

Best regards,
Paul

>All suggestions would be truly appreciated -- I'll be more than happy to 
>try and follow any suggested cures, and will obviously share the outcome here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20121017/4642e0c1/attachment.htm>