[OPEN-ILS-DEV] ***SPAM*** Re: MFHD Commit to Serials Branch

[Bill Erickson]

On Mon, May 3, 2010 at 11:35 AM, Dan Wells <dbw2 at calvin.edu> wrote:

> Hello all,
>
> I have committed my MFHD code changes to the new Serials branch for review
> and comment from anyone interested.  You can see the changeset (with more
> details) here:  http://svn.open-ils.org/trac/ILS/changeset/16373
>
> At this point I cannot guarantee that the interface is 100% stable, as I
> realized while working with the code that some of the new methods may be
> better suited to be members of the Caption object, but I will certainly
> preserve and pass through where it makes sense to do so.  Still, there is
> plenty here to chew on, so I wanted to get this out right away.
>
> I should also note that this module now requires a new, not-yet released
> version of Marc::Record for the *field methods to work properly.  You can
> get the updated code from Source Forge repository:
> http://sourceforge.net/projects/marcpm/develop
>
> Please let me know if you have any corrections or suggestions.
>


Dan++

I have some questions/comments related to the integration project in
general.

1.  I'd recommend keeping the seials-integration [sic] branch up to date
with trunk.  It will make the final merge much simpler.  I've used svnmerge
[1] in the past with success.

2. I'd like to offer our assistance getting the serials schema defined in
the wiki [2] into trunk.  (FWIW, I'm suggesting trunk instead of the
integration branch for several reasons.  Dealing with upgrade scripts in a
branch won't be fun, trunk already has a serials schema in progress, the
integration branch can absorb the changes (via svnmerge), and there are
other features related to serials and ACQ that are pending the integration
of the serials schema).

What outstanding changes need to be made to the schema before it's brought
in?
* I recall some discussion of dropping the unique constraint on
serial.shelving_unit.call_number.
* Do we need a serials.distribution.owning_lib column to cover the scenario
where serial.record_entry is owned by the root org unit?
* I'm inclined to leave serial.claim out until we know how acq.claim might
affect things.
* What else?

Thanks Dan

-b

[1] http://www.orcaware.com/svn/wiki/Svnmerge.py
[2]
http://evergreen-ils.org/dokuwiki/doku.php?id=acq:serials:basic_predicting_and_receiving&s[]=serials

-- 
Bill Erickson
| VP, Software Development & Integration
| Equinox Software, Inc. / Your Library's Guide to Open Source
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20100503/9cb4d66f/attachment.htm