Hi Mike,
I grabbed SQLAlchemy from pypi when it was still there so I could do a
quick test with my current projects (yay for buildout with version
pinning). I'm happy to be able to report that the upgrade was seemless,
and all my tests were passing with 0.7b1.
Wichert.
On 2/13/11 01:51 , Michael Bayer wrote:
Hey list -
The first beta release of SQLAlchemy 0.7 is available for download.
0.7 is the latest iteration of our yearly cycle where each new version brings
lots of new features and enhancements, refines APIs and patterns while
deprecating others, and removes old APIs that have been deprecated for at least
one major revision series (i.e. throughout 0.6).
The initial push in 0.7 focuses on a reorganization of the "event" system. Over the years we've
accumulated various "Extension" classes like MapperExtension, SessionExtension, as well as core
constructs like ConnectionProxy, PoolListener, and then a bunch of other more surreptitious systems like
class instrumentation events, schema association events that were not fully public. In 0.7, everything
resembling an event is now available through a single unified API called "sqlalchemy.event". It's
a single import of a single function listen() that serves as the gateway to associating user-defined
callables with all events throughout the core and ORM. All the Extension classes and similar still remain
for the time being, their underlying implementations now routing through event.
At the same time as "event" was going on, I found myself using Ants Aasma's "derived attributes" example like crazy in my day job. This system allows the construction of Python
class attributes that produce a Python result at the object level and a SQL expression at the class level, building upon the paradigm already present in a SQLAlchemy mapped class. I enhanced the
example in 0.6 such that special cases where the two situations weren't completely symmetrical could be implemented using some additional directives. It became apparent that the extremely simple
idea in "derived attributes" was really a superset of "synonym", "comparable_property", and to some degree "composite()". So in 0.7 we've
"mainstreamed" "derived attributes" as "sqlalchemy.ext.hybrid". The "synonym", "comparable_property", and "composite" APIs have been
refactored such that their usage is mostly the same as it was previously, but their underlying implementation uses approximately the sam
e concept as ext.hybrid, and their implementations have been moved out of the core ORM
modules, allowing us to simplify some things internally. The documentation now
encourages the usage of sqlalchemy.ext.hybrid for "customized" attributes that
produce new expressions derived from the class and also function at the instance level,
in lieu of synonym and comparable_property.
The third story of 0.7 is that we did a lot more work on speed, which includes that we've come up with a viable replacement for
the "mutable" behavior of certain types, mainly PickleType, composite(), and postgresql.ARRAY. The
"mutable" flag on these types is now turned off by default - while the old system of detecting "in place
mutation" was fine for small jobs, it completely cripples the application as it begins to handle higher volumes of data, as
it relied upon scanning all "mutable" objects in the Session in order to detect changes in these attributes. The
autoflush operation basically becomes O(N) instead of O(1) the minute an object with a "mutable" attribute is placed in
the session.
A new system which allows one to construct "on change" events specific to the kind of data structure being stored in a
scalar value is added in "sqlalchemy.ext.mutable". This is a brand new system that hopefully should grow as we move
through 0.7 to support various Python structures out of the box, like dicts, lists and composites of those. The turning off of
"mutable" is likely the one most major "hard change" in the system - if your application relies upon in-place
mutation of PickleType or postgresql.ARRAY, you'd need to turn that flag on until your app can be altered to use the new system.
If your application relies upon in-place mutability of composite() (I'm assuming this is a very rare scenario, composite() isn't
that common in the first place), the new system has to be used for that, which requires a little bit of modification to the
user-defined composite class. Heavy users of "mutable" should notice an immediate effect by switching off of the old
system.
A long list of everything to be aware of is ready for viewing at
http://www.sqlalchemy.org/trac/wiki/07Migration . While there are many
changes, it is my impression that the vast majority of applications coded
against 0.6 will run on 0.7 without modification, Very few changes are
backwards incompatible, and of those fifteen changes which are, most are things
that were never documented or were essentially silent failures.
The purpose of the beta is to get community feedback on the release, including
any difficulties encountered in upgrading, any regressions noted, experiences
with the new features and their behaviors. There's typically three to five
betas before the 0.7.0 release comes out.
View whats new in 0.7 at:
http://www.sqlalchemy.org/trac/wiki/07Migration
Download SQLAlchemy 0.7b1 at :
http://www.sqlalchemy.org/download.html
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
