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

[Dan Wells]

Hello Bill,

> 
> 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.
> 

Sounds good, I'll do my best to keep up.

> 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).

I agree with this as well.

> 
> What outstanding changes need to be made to the schema before it's brought
> in?

I've been tinkering with the schema quite a bit since our pre-conference conversation, and testing it against various scenarios.  I definitely understand better now the need to have multiple shelving_units per call_number, but also think we cannot give up supporting multiple copies per shelving unit.  It is important for us to know relationally if two copies represent the same shelving_unit (that is, the same content).  So it would appear that shelving_unit is a corollary to neither call_number nor copy, but truly exists at some meta-level which falls in between.  For purposes of easier integration and backwards compatibility, I say we keep it there.  With that in mind, we really have two options:

1) a separate linking table to map copies to shelving units in a many-to-one relation
2) a new 'serial.copy' table which inherits from asset.copy, but adds a reference to shelving_unit

I think these are really two ways to do about the same thing, but since I do not have much experience with inherited tables, the wiki page has been updated to reflect the more traditional approach (#1).  I could rally behind either approach (or still another), though, so more thoughts here are certainly welcome.

> * I recall some discussion of dropping the unique constraint on
> serial.shelving_unit.call_number.

This has been dropped, per above.

> * 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 think this sounds like a reasonable requirement.  It has been added.

> * I'm inclined to leave serial.claim out until we know how acq.claim might
> affect things.

Sounds fine.

> * What else?

I have made a few other changes.  Notably, first, I replaced all DATE columns with TIMESTAMP... columns, as DATEs were not playing nice in a few places.  Second I replaced 'is_expected' and 'is_received' with copies_expected and copies_received, as I believe this supports more use cases without adding much complexity to cases where the change would not be needed.  There are a few other similarly minor changes sprinkled throughout.  I intend to eventually add note tables for Shelving Units and Distributions (the Issuance note table is now there), but just haven't gotten around to it.  They should be straightforward.

Something not quite as straightforward, though, is the idea of having a 'copy template' of some sort.  I have added at least some comments pertaining to the idea of using the copy_transparency table, but as I understand it, that is not quite what was in mind when that table was created.  Still, it or something like it would work and is desirable.

All that said, I think getting this into trunk even more-or-less as-is would be a big step in the right direction.  I have updated the wiki page ( http://www.open-ils.org/dokuwiki/doku.php?id=acq:serials:basic_predicting_and_receiving ) to reflect the schema as it currently exists on my development instance (apologies in advance for any typos!).

As the week progresses, I fully expect to get the bulk of our current serials code into the branch.  I have been concentrating on getting the schema nailed-down for you guys first, so I really hope it helps on your end, and also that we can reach some quick consensus where needed.

Thanks,
Dan

-- 
*********************************************************************************
Daniel Wells, Library Programmer Analyst dbw2 at calvin.edu
Hekman Library at Calvin College
616.526.7133