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 Chris On 17 March 2011 06:09, Archives and Collections Society <paul.a@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 usefulness.
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 :)
[snip] 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.
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.)
[snip] 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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha