[openstack-dev] [all] Switching to SQLAlchemy 1.0.x
joe.gordon0 at gmail.com
Tue Jun 9 18:24:06 UTC 2015
On Tue, Jun 9, 2015 at 8:08 PM, Mike Bayer <mbayer at redhat.com> wrote:
> On 6/9/15 9:26 AM, Thomas Goirand wrote:
>> The python-sqlalchemy package has been uploaded to Debian Experimental,
>> and is about to be uploaded to Debian Unstable. So I wonder what's the
>> state of the project regarding upgrading SQLA.
>> Maybe Mike can tell what kind of issue we may run into? How much work
>> will it be to switch to SQLA 1.0.x for Liberty? Is it possible to be
>> compatible with both 9.x and 1.x (which would be the best way forward)?
> The short answer is that there are no supported use cases that have been
> intentionally changed in any backwards incompatible way in 1.0 and all
> Openstack code should be able to accommodate from 0.9.x -> 1.0.x without
> any change.
Just posted a patch to test this out: https://review.openstack.org/189847
> I run SQLAlchemy's master against a small subset of Openstack tests
> continuously, including Nova DB API, Keystone, all of oslo.db and Neutron's
> migration tests, and there was nothing that needed changing as we went
> along. I've also run devstack against SQLAlchemy 1.0 without problems
> though I don't have a lot of openstack-user-fu so I didn't stress test it
> too much at that level.
> It's my expectation that nothing in Openstack should have to change to
> work with SQLAlchemy 1.0 - the kinds of things that change tend to be
> subtle things related to odd use cases and newer features, usually along
> the lines of applications that may have been relying upon some behavior
> that was undefined, that then changes it's behavior in some way.
> An example is that we had a user who was running a query of the form
> "session.query(SomeObject).with_parent(SomeParent(id=None))", e.g. trying
> to find objects that *didn't* have a parent by using a transient "Parent"
> with "id=None" - totally unexpected way of doing that, and it wasn't even
> working for that user as it came up with an "= NULL" comparison that isn't
> even right, *but* when SQLA 1.0 came around it started leaking an internal
> symbol into the query, and *then* it became noticeable. That's the kind of
> thing that "breaks" with new SQLAlchemy versions these days. We had a lot
> of those this time around, and the vast majority of them were logged as
> regressions which were fixed and added to testing. You can see those by
> browsing versions 1.0.1 -> 1.0.5 at
> We never intentionally make *any* backwards incompatible change in just
> one major version without warnings being emitted in the previous version,
> and the warnings usually involve urging the user to set a flag to "use the
> old way" if they're going to upgrade; that is, we at least always try to
> add flags to keep an old behavior in place if at all possible. I've not
> seen anything in Openstack that would be sensitive to this kind of issue
> for 1.0.
> So for Openstack, we would mostly worry about code that is doing things
> oddly in some unexpected way, however all the Openstack code I've seen
> tends to be very ORM centric and uses the ORM very conservatively so I
> don't anticipate any problems. I would note that some silently-/ quasi-
> failing use cases for query.update() and query.delete() now raise
> exceptions in 1.0. They both emit warnings in 0.9 but I just checked and
> apparently one of these warnings is only in the as-yet unreleased 0.9.10.
> I've just added an extra migration note for one of these which appeared to
> be missing in the migration document (as of this writing it should be up on
> RTD within an hour).
> That said, the document which tries to capture everything that might be
> surprising is at
>> Thomas Goirand (zigo)
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev