Now approaching the end of our Koha (3.02.05.000 on Ubuntu 10.10) implementation of barcodes is the next "problem" to be resolved. There seems to be very little Koha documentation on the subject and what little there is either "not to be used", "deprecated" (e.g hbyymmincr.pm which looked promising but "This format is deprecated and SHOULD NOT BE USED") or has been relegated to "dead files" e.g. <http://wiki.koha-community.org/wiki/Barcode_Prefixes_in_Consortial_Environment_RFC> is now found in the "Abandoned RFC" part of the Wiki. There is a default "generated in the form <branch>yymm0001" in admin -> sys preferences, which is close to what we require (replace "branch" - this would be a constant without practical value to us - with first four letters of "call number") but no obvious means of getting there. [Already we have rewritten callnumber.pl (nonfunctional) as acscallnumber.pl and use it for the callback on new items set as default through the admin interface Marc Subfield structure|edit|more constraints|plugin AND have written a separate perl routine for batch imports.] We can obviously modify barcode.pl and write a batch import routine, as this appears to be similar or parallel to the callnumber routines. However, this requires the 'SHOULD NOT BE USED' module above. So the questions are: - are we missing something? - is there some documentation (barcodes in general, coding|scripting in particular) that someone can kindly point us to? - what are the reasons for the various 'deprecated', 'should not be used', 'abandoned labels'? and what pitfalls are we opening ourselves to? what are the replacements? Our thoughts revolve around our overall respect for all the development that has gone into Koha (thank you all) - it is a remarkable project. But also around the quasi-total lack of technical documentation. We are still attempting to map the logic and data flows in the Koha architecture. We are still struggling with messy implementations of Zebra which has to be reindexed after every rewrite to koha.db during batch jobs (12,000 operations take 10 hours on fast hardware - but cannot find any documentation e.g. why the daemon must be replaced by a cron job, which might be very pertinent) - and we're going to have to do this again for barcodes. Any assistance and advice would be appreciated. We (Pete, who also posts here, and myself) are pretty thick-skinned so please do not hesitate to tell us that we have missed out on simple solutions. Thanks and regards, Paul Tired old sys-admin --- Archives and Collections (ACS) Society 205, Main Street, Picton, Ontario, K0K 2T0, Canada http://www.AandC.org Canadian Charitable Organization 88721 9921 RR0001 Dedicated to maritime conservation and education.
Hi Paul, On Wed, Mar 16, 2011 at 10:50 AM, Archives and Collections Society <paul.a@aandc.org> wrote:
Now approaching the end of our Koha (3.02.05.000 on Ubuntu 10.10) implementation of barcodes is the next "problem" to be resolved. There seems to be very little Koha documentation on the subject and what little there is either "not to be used", "deprecated" (e.g hbyymmincr.pm which looked promising but "This format is deprecated and SHOULD NOT BE USED") or has been relegated to "dead files" e.g.
I am the one who is responsible for the hbyymmincr format. In hindsight it was a bit redundant as the homebranch can be included on the label without having to include it in the barcode. But at the time, it seemed a good thought. A critical limitation to this format is that it is only good for 9999 barcodes per month. While in production this might be ok, if one was doing a initial load of > 9999 items it would present a serious limitation on this format's usefulness. It is maintained because the library here is using it and in all probability there are others who may be using it. I'm sure we could fix up the code to raise the limit, but it probably is not worth the effort, imho.
<http://wiki.koha-community.org/wiki/Barcode_Prefixes_in_Consortial_Environment_RFC> is now found in the "Abandoned RFC" part of the Wiki.
I cannot speak to that, sorry.
There is a default "generated in the form <branch>yymm0001" in admin -> sys preferences, which is close to what we require (replace "branch" - this would be a constant without practical value to us - with first four letters of "call number") but no obvious means of getting there. [Already we have rewritten callnumber.pl (nonfunctional) as acscallnumber.pl and use it for the callback on new items set as default through the admin interface Marc Subfield structure|edit|more constraints|plugin AND have written a separate perl routine for batch imports.]
We can obviously modify barcode.pl and write a batch import routine, as this appears to be similar or parallel to the callnumber routines. However, this requires the 'SHOULD NOT BE USED' module above.
So the questions are: - are we missing something? - is there some documentation (barcodes in general, coding|scripting in particular) that someone can kindly point us to? - what are the reasons for the various 'deprecated', 'should not be used', 'abandoned labels'? and what pitfalls are we opening ourselves to? what are the replacements?
Have you had a look at the POD for C4::Barcodes? http://perldoc.koha-community.org/v3.02.05/C4/Barcodes.html This includes some brief direction for adding other formats.
Our thoughts revolve around our overall respect for all the development that has gone into Koha (thank you all) - it is a remarkable project. But also around the quasi-total lack of technical documentation. We are still attempting to map the logic and data flows in the Koha architecture. We are still struggling with messy implementations of Zebra which has to be reindexed after every rewrite to koha.db during batch jobs (12,000 operations take 10 hours on fast hardware - but cannot find any documentation e.g. why the daemon must be replaced by a cron job, which might be very pertinent) - and we're going to have to do this again for barcodes.
The daemon has memory leak problems. You are well advised to run away from it as fast as possible. There should be no reason to totally reindex afaik. You can run rebuild_zebra.pl -b -a -z and just catch the new/modified records. See http://tinyurl.com/4u4vtoz for an example of how to setup your rebuild in cron. Kind Regards, Chris
participants (2)
-
Archives and Collections Society -
Chris Nighswonger