On Tue, Jun 9, 2015 at 8:08 PM, Mike Bayer <mba...@redhat.com> wrote:
> > > On 6/9/15 9:26 AM, Thomas Goirand wrote: > >> Hi, >> >> 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 > http://docs.sqlalchemy.org/en/rel_1_0/changelog/changelog_10.html. > > 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 > http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html. > > > > >> Cheers, >> >> Thomas Goirand (zigo) >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev