SQLAlchemy 0.8.0b2 released

[Michael Bayer]

Hi list -

SQLAlchemy 0.8.0b2 is released. This is hopefully the last beta for 0.8, as things have been mostly quiet surrounding 0.8.0b1, we had a few regressions fixed, and a bunch of other new bugs whose fixes are only in 0.8.

There was a little bit of an additional refactor in this beta regarding the mechanics of loader strategies and aliased() constructs, which is to allow ever-more combinations of custom loader strategies in conjunction with "polymorphic" loading, and hopefully the latest architecture in this area will prove to be the most consistent yet.

Other changes include that the Postgresql HSTORE type has been merged into the library, and there's also a handful of dialect fixes, notably several for Oracle. The Sybase dialect now supports schema reflection, and the new "fdb" dialect for Firebird should be working now.

One thing to note here, is that I've put this release on Pypi. I had done this with 0.8.0b1, but then quickly pulled it off, as I had forgotten that tools like pip and easy_install don't honor the "hidden" flag on pypi, so even though I've kept 0.7.9 as the "visible" version, these tools still go out and grab the "hidden" beta - some prominent projects immediately reported that they got bumped up to 0.8 prematurely.

But the effect of only publishing 0.8.0b1 on Sourceforge was that I didn't get the impression that we had so many people going out and testing the beta as we normally do. I was reminded by Chris McDonough that a project which really can't afford to jump to 0.8 on an automatic basis should have a requirement set up to keep them on 0.7. So we'll see how it goes -if your project needs to stay on 0.7, *please* set up a requirement for "SQLAlchemy < 0.8" in your requirements.txt and/or install_requires. Otherwise, you'll be a beta tester for 0.8.0b2.

CHANGES for 0.8.0b2 are available in the documentation at: http://docs.sqlalchemy.org/en/rel_0_8/changelog/changelog_08.html#change-0.8.0b2

Download 0.8.0b2 at:

http://www.sqlalchemy.org/download.html

[Doug Latornell]

Thanks for the new release Mike. Just in time for the holidays! :-)

I was using 0.8.0b1 in 3 recent projects, but none of them were pushing it very hard and everything just worked, so I didn't think I had anything to say. In retrospect, though, I guess "It works for me" is feedback on a beta just as much as bug reports?

Anyway, 2 of those projects have gone into limbo due to corporate psychopathy, but the other one is still going strong and I'll start using 0.8.0b2 in it ASAP.

[Wichert Akkerman]

On Dec 14, 2012, at 22:11, Michael Bayer <mik...@zzzcomputing.com> wrote:
> But the effect of only publishing 0.8.0b1 on Sourceforge was that I didn't get the impression that we had so many people going out and testing the beta as we normally do. I was reminded by Chris McDonough that a project which really can't afford to jump to 0.8 on an automatic basis should have a requirement set up to keep them on 0.7. So we'll see how it goes -if your project needs to stay on 0.7, *please* set up a requirement for "SQLAlchemy < 0.8" in your requirements.txt and/or install_requires. Otherwise, you'll be a beta tester for 0.8.0b2.

There is a small problem here: 0.8b2 < 0.8 with python's versioning rules. There is an alternative spelling though: use "SQLAlchemy < 0.8dev" to make sure all pre-releases for 0.8 are also rejected.

Wichert.

[Michael Bayer]

For a second there I thought you were talking about using "b2" in the first place, then I went and sanity checked against pep386 all over again, but you're talking about the requirement rule - WHEW.

"0.8dev" isn't pep386 compliant:

>>> V('0.8dev') < V('0.8.0b2')
verlib.IrrationalVersionError: 0.8dev

"0.8.dev1" isn't prior to b2:

>>> V('0.8.dev1') < V('0.8.0b2')
False


the best option seems to be "a1":

>>> V('0.8a1') < V('0.8.0b2')
True


http://www.python.org/dev/peps/pep-0386/#the-new-versioning-algorithm

[Burak Arslan]

Hi Michael,

This is the only regression I saw migrating from 0.7.9 to 0.8b2:
https://travis-ci.org/plq/spyne/jobs/3711648/#L568

The fix was to remove the pformat call:

https://github.com/plq/spyne/commit/56580c280945e6d484a5f4ce3fbca682ca698778

The sqla_mapper attribute contains the table mapper. It's assigned here: https://github.com/plq/spyne/blob/56580c280945e6d484a5f4ce3fbca682ca698778/spyne/util/sqlalchemy.py#L550

So it's a pretty standard (yet old-fashioned) use-case.

Let me know if you need any additional information.

Best,
Burak

[Michael Bayer]

seems like it's hitting some revised rules for evaluating clauses in a boolean context, as pprint attempts to sort the contents of the Mapper object's __dict__.    In particular, you can't say bool(Column('x') > Column('y')) anymore, in 0.7 it would basically make a random guess as to what the result should be (comparing the id() of each), but some problems were hit with this, so the behavior was made more strict in 0.8.   Only bool(Column('x') == Column('y')) has a meaningful result now.

However I'd offer that pprint is not really an appropriate system for rendering a Mapper object:

http://docs.python.org/2/library/pprint.html

"If the formatted structures include objects which are not fundamental Python types, the representation may not be loadable. This may be the case if objects such as files, sockets, classes, or instances are included, as well as many other built-in objects which are not representable as Python constants."

Observing how pprint works, I'd say it's really more for fundamental data structures and not application-specific class instances.

--
You received this message because you are subscribed to the Google Groups "sqlalchemy-devel" group.
To post to this group, send email to sqlalche...@googlegroups.com.
To unsubscribe from this group, send email to sqlalchemy-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sqlalchemy-devel?hl=en.