[OPEN-ILS-DEV] libjs

[Mike Rylander]

On 2/11/07, Mike Rylander <mrylander at gmail.com> wrote:
> On 2/11/07, Eric Lesage <lesagee at iro.umontreal.ca> wrote:
[snip]
> >
> > I'll be making an ebuild in my tree along with 1.0.2 (thanks about that
> > BTW), at least until it gets picked up by the official tree. It should be
> > no more complicated that the version I already provide (based on CVS). I
> > started working on this earlier today.
>

And just to keep things EXTRA fun, we've put out a little bug-fix
release, 1.0.2.2.  This is a direct code overlay, with no underlying
DB changes, so nothing to think about there...

However, further down in this thread (I'm responding here due to
laziness, mainly), Eric said:

> Now, there's one issue we've already touched on previsouly, and that is
> the question of DB schema updates, and versioning tables. My ebuild
> doesn't address this at all. Most of the changes are in the reporter
> schema, so it's not too bad for now, but some are about permissions, etc.
>
> I haven't had the chance (haha) to personally encounter these problems
> myself as a software developer, so I'm not sure what's the best way to
> handle this. But, I think the "initialization data" (default
> users/permissions) should be kept distinct from the schema itself -- it
> becomes clearer what should be updated, and what should stay inherited
> from the current setup (well... as long as a particular setup doesn't
> stray too much away from the distribution -- something for FIT).

Right.  That's exactly the direction I want to go as we work towards
1.2, so please keep me in check there.  For the remainder of 1.0, it
doesn't seem like it's worth the effort to extricate ourselves from
the current situation, so I'm not going to worry about it too much.  I
doubt very highly that anyone other than PINES will be going live on
the 1.0 code, and if they are they can always come here (or talk to a
commercial interest) for help.

As far as upgrades at the schema level go, there are some very thorny
problems to take into account.  At the base, it's relatively easy to
create a pile of ALTER TABLE and like commands   that will do most of
the work, but it's never going to be that easy for non-trival
installations.  With that in mind, I want to avoid schema changes
(post-1.0.x) inside any major release that can't be handled with
/very/ trivial upgrade SQL -- and entirely if possible. So, starting
with 1.2, how about ...

Given a version number constructed like X.Y.Z.abc :

* X is the version number.  Major schema changes requiring extensive
planning and scripting are allowed here.  Wholesale replacement of
locally constructed components is also allowed, but should be avoided
where possible.  The existing API, transport mechanisms, etc may
change entirely.

* Y is the major release number.  Minor schema changes requiring some
local adjustment of upgrade scripts is allowed, but should be avoided
if possible.  Minor changes to existing APIs are allowed, and should
be expected.  Replacement of locally constructed components is
allowed, but should be restricted to areas where required API changes
have taken place.

* Z is the minor release number.  Only minor additions, but not
changes, to the existing schema are allowed, and should not require
any local scripting beyond the consideration of replication
environments.  Additions to the API are allowed, but change to
existing API constructs should be avoided as much as humanly possible.
 Replacement of local changes should not happen.

* abc is the fix/forgot/patch release number.  No schema changes
whatsoever.  Bug fixes and "ooops, forgot to check that in" features
are the only thing allowed here.

That's just off the top of my head and may need to be reworked a good
bit, but comments would be appreciated.

> There are of courses many issues with this, especially with decentralized
> software. I've not analyzed if/how you version interfaces elsewhere (i.e.,
> for opensrf services) and how deep the schema affects the services... At
> some level one must take care that all services run on a coherent idea, or
> that provisions are made for multiple concurrent interfaces.

OpenSRF actually has a mechanism for versioning the API such that
later clients can take advantage of increased functionality using the
same method names.  This is something that I'd personally love to see
us exploit, but it isn't really needed right now -- the API is getting
broader but not changing internally.

As far as the DB affecting the staff-client-level API and the middle
layer (via object definitions and the like), that's taken care of by
the IDL XML.  A new version of the IDL is installed with each release
and surrounding code is generated based on that.  The staff client
gets this code remotely, and the middle layer and backend use the IDL
directly to construct queries (SQL and otherwise).

Is that generally what you were asking about?

-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org