[Koha-bugs] [Bug 11096] Koha cannot retreive big records from Zebra

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11096

David Cook <dcook at prosentient.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Needs Signoff               |Failed QA
                 CC|                            |dcook at prosentient.com.au

--- Comment #3 from David Cook <dcook at prosentient.com.au> ---
I've applied the patches, but I'm still unable to retrieve the big record from
Zebra.

I created a new bib record with an excessive number of 5xx fields and added
many items, and it has created problems with the MARC record leader.

This is the leader for a small record:
<leader>03322cam a2200469 a 4500</leader>

Here is the (broken) leader for a big record (without items) in MySQL:
<leader>143530nama22006133  45000</leader>

Here is the (broken) leader for a big record (with items) in Zebra (accessed
via YAZ):
<leader>584260nama22019693  4500</leader>

As you can see, both of the broken leaders are quite broken. The MySQL version
is 25 characters rather than 24. In Zebra, it has 24 positions, but much of the
data are in the wrong place because of that 6 character record length.

--

When I try to access the record in Yaz-client, I receive the following error:

<!-- Directory offset 276: Data out of bounds 59725 >= 58426 -->
</record>

As Tomas pointed out, 584260 has been shortened to 58426 as Yaz is expecting 5
characters rather than 6 characters for the record length.

--

So...at the moment...it seems that indexing and retrieving oversized records
doesn't work.

If you try to bring up a detail page manually, you can, but the XSLTs won't
work correctly as it can't rely on the leader positions correctly. A "book"
might show up as a "set".

In one case, some of the XSLT display isn't even showing because the data that
is mixed around is totally unusable.

--

Admittedly, the most likely causes of big records are notes and items, so
perhaps it would make sense to separate out the item records from the bib
records when indexing. 

As for the notes...I'm not sure how we would handle that. While there is a 9999
character limit on a note field, you could have a hundred note fields that
break your record.

--

I'm not really sure what the answer is, but here is the problem.

-- 
You are receiving this mail because:
You are watching all bug changes.