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

[Bill Erickson]

On Mon, May 3, 2010 at 6:59 PM, Dan Wells <dbw2 at calvin.edu> wrote:

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


If we need to support multiple shelving_unit's per call_number (honestly, I
missed the crux of the debate), then this approach seems reasonable to me.
The mapping table makes sense, since we are, as you indicated, representing
another dimension to the relationships between these objects.



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

Similarly, dropping serial.issuance.has_claims, since that will likely be a
derived value, based on the existence of claim data.


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

copies_expected and copies_received is a count?  I wonder if we'll need more
copy-level details like recv_date for individual copies, etc.


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

This, in conjunction with my question above, creates some disturbing
similarities to how acq.lineitem_detail's are used ;)  It's basically a
proto-copy with some values populated manually and/or from org_unit
settings, and some auto-generated at real copy creation time.  Integrating
the ACQ code at that level could very well be massive overkill for serials,
though.


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

Will keep digesting this...

Thanks Dan

-b

-- 
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/20100504/31cdcb3f/attachment.htm