Here we go > > http://www.nntp.perl.org/group/perl.perl4lib/2006/05/msg2369.html From this email, as I understand it, it seems that here is the reason why Koha in search result deserialize MARC records from their ISO2709 representation rather than their MARCXML. If we were able to use marcxml,
Other reason is that deserializing from xml rather than iso2709 is WAY slower and proc intensive. It would not be a problem is any setup would CORRECTLY and SENSIBLY use XSLT. But since XSLT.pm is what it is ie taking marc record, editing, tranforms to xml before processing xslt, this process would only be slower if we used xml. Moreover the main reason why record are bigger than 9999 bytes is because of items. It is proven that it would really be HEALTHY to remove them. So the problem wouls not exist any longer. My 2 cts. -- Henri-Damien Laurent Le 12 nov. 2010, 7:55 AM, "Frédéric Demians" <frederic@tamil.fr> a écrit : the 99,999 limitation for MARC record size could be exceed. And we would have one less reason to move to SolR--notwithstanding the other reasons to move to. -- Frédéric _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-comm...
Both LEK and PTFS Koha (>=1.2) apply this tactic of using MARCXML (with dynamic item data insertion) as the authoritative source to enable bibs with large numbers of items. The tradeoff is indeed that it is slower than parsing the binary MARC data, but there are optimizations available to compensate. The helpful part is that the extra processing time only becomes noticeable to the user when they come across the large records that Koha could not have previously handled because of the 9,999 constraint. Clay 2010/11/12 Henri-Damien LAURENT <henridamien.laurent@gmail.com>
Other reason is that deserializing from xml rather than iso2709 is WAY slower and proc intensive. It would not be a problem is any setup would CORRECTLY and SENSIBLY use XSLT. But since XSLT.pm is what it is ie taking marc record, editing, tranforms to xml before processing xslt, this process would only be slower if we used xml. Moreover the main reason why record are bigger than 9999 bytes is because of items. It is proven that it would really be HEALTHY to remove them. So the problem wouls not exist any longer. My 2 cts. -- Henri-Damien Laurent
Le 12 nov. 2010, 7:55 AM, "Frédéric Demians" <frederic@tamil.fr> a écrit :
Here we go > > http://www.nntp.perl.org/group/perl.perl4lib/2006/05/msg2369.html From this email, as I understand it, it seems that here is the reason why Koha in search result deserialize MARC records from their ISO2709 representation rather than their MARCXML. If we were able to use marcxml, the 99,999 limitation for MARC record size could be exceed. And we would have one less reason to move to SolR--notwithstanding the other reasons to move to. -- Frédéric
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-comm...
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I'd like to add my 2cts. to the reasons for removing items from the bibliographic record. We have many records with thousands of items. This is often the case with long-running serial publications in academic institutions. In the case of archival institutions like ours, we are talking about decades if not centuries of a record series. To split them into groups just because they don't fit within the 9999 byte limit is doable, but not logical, in my own (limited and aging) mind. Thanks. -- Linda Culberson lculber@mdah.state.ms.us Archives and Records Services Division Ms. Dept. of Archives& History P. O. Box 571 Jackson, MS 39205-0571 Telephone: 601/576-6873 Facsimile: 601/576-6824 On 11/12/2010 8:43 AM, Henri-Damien LAURENT wrote:
Other reason is that deserializing from xml rather than iso2709 is WAY slower and proc intensive. It would not be a problem is any setup would CORRECTLY and SENSIBLY use XSLT. But since XSLT.pm is what it is ie taking marc record, editing, tranforms to xml before processing xslt, this process would only be slower if we used xml. Moreover the main reason why record are bigger than 9999 bytes is because of items. It is proven that it would really be HEALTHY to remove them. So the problem wouls not exist any longer. My 2 cts. -- Henri-Damien Laurent
Le 12 nov. 2010, 7:55 AM, "Frédéric Demians" <frederic@tamil.fr <mailto:frederic@tamil.fr>> a écrit :
Here we go > > http://www.nntp.perl.org/group/perl.perl4lib/2006/05/msg2369.html
From this email, as I understand it, it seems that here is the reason why Koha in search result deserialize MARC records from their ISO2709 representation rather than their MARCXML. If we were able to use marcxml, the 99,999 limitation for MARC record size could be exceed. And we would have one less reason to move to SolR--notwithstanding the other reasons to move to. -- Frédéric
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-comm...
participants (3)
-
Clay Fouts -
Henri-Damien LAURENT -
Linda Culberson