[OPEN-ILS-DEV] libjs

[Eric Lesage]

On Tue, 13 Feb 2007, Mike Rylander wrote:

> On 2/11/07, Mike Rylander <mrylander at gmail.com> wrote:
>
> 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.

Ok.

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

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

Sounds good. (Maybe you'd want to coordinate the nomenclature with the 
wiki.)

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

Yes, thank you for the information. What I was looking at was the question 
of availability. What I gather is that when there is a system upgrade, a 
given staff client is tolerant enough to refetch the IDL and work with it 
even if the tables have changed a bit, so not everything has to be done at 
once (well, up to the limits defined in the version scheme you defined).

Regards,

-- 
Eric Lesage