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

[Jared Camins-Esakov]

Paul,

Would one of you please be kind enough to save my sanity (if I have any
> left)?
>
> 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.


> 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/detail.pl?biblionumber=XXXX (easiest is to just
view another record, then change the biblionumber in the URL).


> I have a feeling that all this is "associated with" Bug 8665, but would
> appreciate a little more understanding (is there a full write up somewhere?
> I've searched but can't find one.)  I believe that 3.6 (at least .1, but
> changed sometime before .7) used biblionumber as the primary reference; now
> field 001 has become "primary."  Why?  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.

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.


> 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.
>

Regards,
Jared

-- 
Jared Camins-Esakov
Bibliographer, C & P Bibliography Services, LLC
(phone) +1 (917) 727-3445
(e-mail) jcamins at cpbibliography.com
(web) http://www.cpbibliography.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20121017/5008062c/attachment.htm>