[OPEN-ILS-DEV] Serials Schema Tweaks for Alpha2 Release

[Mike Rylander]

On Wed, Sep 15, 2010 at 2:27 PM, Dan Wells <dbw2 at calvin.edu> wrote:
> Hello Mike,
>
> Sorry for my slow reply, things are pretty hectic around here with the Fall semester starting last week.
>
>>
>> Can you describe the purpose of these?  Some seem obvious, but some
>> are not (to me).
>>
>
> I will start with the changes which I think are straightforward.  First, textual_holdings are sometimes used to augment the generated_coverage and at other times should completely replace it (generally when the holdings statement is too complex to be easily generated or has more detail than we care about).  The 'show_generated' flag in each summary table is a simple means of indicating which type of display we want.  Second, 'summary_method' will be consulted when generating the 'generated_coverage' fields, and tells us how any attached MFHD records (SREs) should be treated for this distribution in relation to the new structured data (attempt to merge the data, generate display data from both separately, or generate based on one or the other only).
>
> The changes to serial.caption_and_pattern are not as straightforward, but I think they are justifiable.  Any given caption/pattern is only valid for a certain period of time (i.e. until it changes).  As it stands, we can infer the start and end dates of a caption/pattern only by consulting the attached issuances.  In practice this means retrieving and sorting sometimes hundreds of issuances to provide for the sorted display of just a few caption/patterns.  As I work with these objects more, I am simply often wishing for a more convenient access point to this important data.  This also means that the 'active' flag is redundant (caption/patterns with end_date-s are not active), but we need to get end_date in place before we can start removing the 'active' flag from the code.
>

Heh, I was actually more sure of the start and end dates, and less
sure of the others... in any case, the only part I have a concern with
is the hard coding of the summary_method_check values.  I'd rather see
a table, if there's any chance of that expanding, though there may not
be.

(Related, the serial.item.status really does need a table + fkey if
for no other reason than I18N, but we can handle that later.)

>> Are there IDL changes to go along with this?
>>
>
> I didn't provide an IDL patch simply for lack of time, and wanting to get this in before the schema was frozen for a few months.  I will happily provide one once this discussion concludes.
>

Understood.  Like I said, these are non-scary because of the defaults
and nullness.  I'll get them committed to trunk and 2.0 tonight,
unless someone has objections.

Note, also, that the schema isn't freezing in trunk, just 2.0.

Thanks, Dan!

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com