[Koha] Barcodes - various thoughts and questions

Chris Cormack chris at bigballofwax.co.nz
Thu Mar 17 07:13:05 NZDT 2011

Hi Guys

Good discussion below, but can we shift it to the koha-devel list
please (cced in)

Makes searching for these kind of development threads much easier if
the are the development list


On 17 March 2011 06:09, Archives and Collections Society
<paul.a at aandc.org> wrote:
> Hi Chris,
> Many thanks... comments inserted into [snipped for relevency] text below"
> At 12:50 PM 3/16/2011 -0400, Chris Nighswonger wrote:
>> > [snip] 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
> Yes, but we would modify it along the following lines (Note: we are not
> necessarily following the "standard" CLSI 14 digit format[1], although I
> think we would want to tend that way):
> <branch> replaced by 4 digit category (think sub-branch as in "navy",
> "merchant marine", "oceanography"); then yymm; then increment based on
> *separate* increment per sub-branch. No initial load or subsequent batch
> would be > 9999.
> Q: we would prefer to use alpha for "sub-branch, but fear this breaks
> industry standards. Yes? No? and can Code128 checksums be implemented?
>>I'm sure we could fix up the code to raise the limit, but it probably
>>is not worth the effort, imho.
> If you wrote the original .pm, could we possibly prevail upon you to draft
> a mod|fix as described above? We'd do testing and fine tuning and give the
> results back to the community :)
>>Have you had a look at the POD for C4::Barcodes?
>>This includes some brief direction for adding other formats.
> Yes, as you say - brief. We're also somewhat confused on the background and
> Koha use of $types hashref. Is there a more complete doc somewhere? (I
> can't find it.)
>>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.
> Yes - we implemented that very early in our process; set to every minute,
> overhead on incrementals seems very low. However, for batch jobs this has
> to be done for *every* write to koha.db, hence our 12,000 records taking 10
> hours.
> Best regards - Paul
> [1] 14 digits:
> 1:ItemType  2-5:[Sub]Branch|Category  6-9:YYMM  10-13:Increment  14:Checksum
> ---
> 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.
> _______________________________________________
> Koha mailing list  http://koha-community.org
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha

More information about the Koha mailing list