[OPEN-ILS-DEV] IDL is not backward compatible?

[Daniel Wells]

Hello Ken,

This is an interesting problem and proposal.  It might be possible to make
some improvements, but there will be certain headwinds.  For example,
system-level flags (e.g. ->ischanged) are already appended to the end of
each fm object array, so even adding named fields to the "end" still adds
them to the "middle", from a certain perspective.  In addition, the IDL is
currently used to apply default field order to various interfaces, such as
the reporter, so keeping the fields intellectually organized is of some
benefit there.  Not saying a change can't be done, just mentioning a few
challenges.  I am sure there are more.

Overall, though, Evergreen doesn't currently have any formal guarantee of
API stability across different versions (that I am aware of).  This means,
at least at the major version level, if not the major.minor version, a
separate client/app would be expected for each release.  In the case of the
app, you can obviously get away with being looser, and that is making life
easier for you.  It still seems worth it as a community to discuss if there
can be a middle ground where certain APIs are defined as stable across a
larger number of releases, especially those used directly by the patron.

All this said, for the case in point, I would suggest regularly checking
the server itself for the ILS version, then reloading the IDL accordingly.
As mentioned, this won't guarantee a non-breaking change, but it would get
you a lot closer.  All the Perl services can return the ILS version, as it
is baked into the Application base module.  E.g.:

http://ulysses.calvin.edu/osrf-gateway-v1?service=open-ils.cat&method=opensrf.open-ils.system.ils_version

That's going to be really lightweight, and should be done at a minimum on
each login, I would think, if not at other opportune moments.  Whenever you
see it change, a new IDL will be needed.

There's more to be said, but to limit cross-posting with other eager
contributors, I'll stop there.

Sincerely,
Dan


On Mon, Feb 18, 2019 at 6:12 PM Ken Cox <kenstir at gmail.com> wrote:

> I think I know what is going on, but I would like somebody to confirm
> my understanding.
>
> After a server upgrade from 3.0.1 to 3.2.2, I saw a significant spike
> the iOS app crashes.  It looks like a cached IDL specifies fewer
> fields than is returned by the /osrf-gateway-v1 endpoint.
>
> I fixed the app so that does not cause a crash, reasoning that since
> the IDL fields must be newly added fields, and because the app didn't
> require them, I could safely ignore them.  On deeper inspection, it
> looks as though new fields have been added to the middle of IDL
> classes.  For instance, the class 'au' had the following new fields
> added, all in the middle:
> * Privacy Waiver Entries
> * Preferred Prefix
> * Preferred First Name
> ...
>
> Short term, I think a partial fix is to disable caching of the IDL,
> even though the server indicates it can be cached:
>
>     HTTP/1.1 200 OK
>     Date: Mon, 18 Feb 2019 09:27:03 GMT
>     Cache-Control: max-age=31536000
>     Expires: Tue, 18 Feb 2020 09:27:03 GMT
>
> Long term, I think a better approach would be to add new fields only
> at the end.  This is a common technique for maintaining binary
> compatibility in compiled code.  If the app is suspended during a
> server upgrade, and if fields are added in the middle, then the IDL is
> out of sync, right?  Or maybe, all sessions are lost during the down
> time and the next request with an auth token will fail, and the IDL
> should be loaded on every login?  (Sorry I have been trying to test
> this hypothesis but I am having trouble upgrading my own EG server).
>
> Thanks,
> Ken
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20190218/a8264286/attachment.html>