<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 9, 2015 at 8:08 PM, Mike Bayer <span dir="ltr"><<a href="mailto:mbayer@redhat.com" target="_blank">mbayer@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
On 6/9/15 9:26 AM, Thomas Goirand wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi,<br>
<br>
The python-sqlalchemy package has been uploaded to Debian Experimental,<br>
and is about to be uploaded to Debian Unstable. So I wonder what's the<br>
state of the project regarding upgrading SQLA.<br>
<br>
Maybe Mike can tell what kind of issue we may run into? How much work<br>
will it be to switch to SQLA 1.0.x for Liberty? Is it possible to be<br>
compatible with both 9.x and 1.x (which would be the best way forward)?<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>Just posted a patch to test this out: <a href="https://review.openstack.org/189847">https://review.openstack.org/189847</a></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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.<br>
<br>
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.<br>
<br>
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 <a href="http://docs.sqlalchemy.org/en/rel_1_0/changelog/changelog_10.html" target="_blank">http://docs.sqlalchemy.org/en/rel_1_0/changelog/changelog_10.html</a>.<br>
<br>
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.<br>
<br>
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).<br>
<br>
That said, the document which tries to capture everything that might be surprising is at <a href="http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html" target="_blank">http://docs.sqlalchemy.org/en/rel_1_0/changelog/migration_10.html</a>.<div class=""><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>