I'm beginning work on courtesy (predue) notices and a re-architecture of
the existing overdue notice script for better templating and
configuration. Attached is a sample configuration section (from
opensrf.xml) I created for setting these up. I wanted to work backwards
from the
Applied with thanks.
2008/8/6 Kevin Beswick [EMAIL PROTECTED]:
Here is a patch to add the new opensrf-perl.pl script to the autotools
build for OpenSRF.
By the way, for future reference, what is the difference between
dist_bin_SCRIPTS and bin_SCRIPTS?
--
Dan Scott
Laurentian University
Hi Bill:
2008/8/6 Bill Erickson [EMAIL PROTECTED]:
I'm beginning work on courtesy (predue) notices and a re-architecture of the
existing overdue notice script for better templating and configuration.
Excellent!
Attached is a sample configuration section (from opensrf.xml) I created for
On Wed, 06 Aug 2008 13:00:48 -0400, Dan Scott [EMAIL PROTECTED] wrote:
Hi Bill:
2008/8/6 Bill Erickson [EMAIL PROTECTED]:
[snip]
Some general comments:
It's not explicit, but I suspect this could be used/abused for items
like laptops that might have a four hour circulation period, so
I have about 960 000 bibliographic records I need to import into an
Evergreen system. The database server is dual quad-core Xeons with
24GB of RAM.
Currently, I've split the bibliographic records into 8 batches of
~120K records each, did the marc_bre/direct_ingest/parellel_pg_loader
On Wed, Aug 6, 2008 at 4:30 PM, Brandon W. Uhlman
[EMAIL PROTECTED] wrote:
I have about 960 000 bibliographic records I need to import into an
Evergreen system. The database server is dual quad-core Xeons with 24GB of
RAM.
Currently, I've split the bibliographic records into 8 batches of
Hey Brandon:
The full text indexes are absolutely the key - check out this thread
from July 2nd:
http://list.georgialibraries.org/pipermail/open-ils-dev/2008-July/003265.html
- I think it addresses your questions for the most part.
And yeah, as Mike notes, we really should document that in the
Thanks, Dan (and also Mike). Great tip!
I think documenting this is a good piece, for sure. Is there any
reason we also wouldn't want to include it in the default SQL
generated by pg_loader/parallel_pg_loader?
If we're concerned about it automatically being called without
checking the
