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 <[email protected]> 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 > [email protected] > http://lists.katipo.co.nz/mailman/listinfo/koha > _______________________________________________ Koha-devel mailing list [email protected] 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/
