[OPEN-ILS-DEV] Proposal: Versioned Add-on Packages

[Mike Rylander]

On Fri, Feb 20, 2009 at 10:00 AM, Scott McKellar <mck9 at swbell.net> wrote:
> --- On Thu, 2/19/09, Mike Rylander <mrylander at gmail.com> wrote:
>
> <snip: proposal on how to make IDL files easier to upgrade in
> the presence of customizations>
>
> To summarize my simple-minded understanding of your proposal:
>
> -- Represent standard IDL classes in one file;
> -- Represent extension classes and site-specific classes in a
>   separate IDL file;
> -- Use a third IDL file at runtime;
> -- Regenerate the third IDL file as needed, by merging the first
>   two whenever either of them changes.
>

Yes.  Though there would be a file per change, generally one per
add-on or local customization.

> That way we can upgrade the standard IDL with a minimum of disruption
> to the customizations.
>
> Some upgrades to the standard IDL may require changes to the custom IDL,
> but those changes will be relatively contained.  It might even be
> possible for the merge process to detect when such changes are needed, though I wouldn't offer or ask for any promises along those lines.

Yes, I'll leave that for later, after the easy stuff is out of the way. :)

>
> I have two questions.  Maybe your post already answered them but I
> didn't grasp the answers.
>
> -----------------
>
> What if a customization adds a column to a standard table?  Does your
> proposal address that situation?  Or does it not happen much anyway?
>

It hasn't happened yet, to my knowledge, and as it is this proposal
would not cover such.   There are some things that make that tricky,
such as the array_position attribute, and I18N stuff (XML entities).

> I don't mean to suggest that the proposal *should* address this
> situation.  Even if it doesn't, it would leave us better off than we
> are now.  However it might be nice if the design didn't make it
> needlessly difficult to add such a feature later.
>

I can think of directions of attack that fit within the "one file per
change" idea, but those ideas are not fully formed (or formed at all)
yet.  I'm attempting to make this as transparent to the rest of the
system as possible, so there's less to change down the road if change
is warranted.

But, it is just a "try" at this point.  If you see anything that looks
like a roadblock to other ideas, please yell about it! :)

> ------------------
>
> Among other things, the IDL expresses foreign key relationships, i.e.
> arrangements whereby a column in a child table refers to a key column
> of a parent table.  In your example, the rmobbhol class has two
> columns pointing to the id column of the aou class.  It is also
> possible (though much less likely) for a custom class to serve as a
> parent for a standard class.)
>
> In many cases (although not in this one) the IDL defines the linkage at
> both ends.  It defines not only a link from the child to the parent,
> but also a link from the parent back to the child.
>
> If a custom IDL defines a linkage from a custom class to a standard
> class, any linkage from the standard class back to the custom class
> would have to be added manually to the standard IDL file.  More
> specifically: if no one adds that linkage manually, the IDL merge
> process will not add it automatically.
>
> Am I right about that?
>

That's correct.  I think we should consider the custom classes as
starting points only -- the standard classes should not be required to
know about them, and if they do need to then it probably means that
the add-on is a candidate for inclusion in the core code.

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