SQLAlchemy 0.3.9 Released

Version 0.3.9 of SQLAlchemy is released.  This is probably not the last of
the 0.3 series, but it's the last major set of changes for this line;
subsequent releases should probably be only for important bug fixes.
0.3.9includes a lot of important bug fixes as usual, but also has a
focus on the
new API which is to be standardized in the upcoming 0.4 series, and is
largely available in SQLAlchemy 0.3.9 so that existing applications can
adapt to the new patterns.  These changes represent improvements by leaps
and bounds over anything SQLAlchemy has ever had, and a lot of them are
available right now.  The documentation has also been updated on the site
with a large portion of these changes - so if you haven't looked at
SQLAlchemy's documentation in a long time, now is the time to revisit;
particularly the chapters on Database Engines, Database Metadata, and Data
Mapping.

So whats changed ?

    - The method of "binding" things to engines, such as MetaData, Sessions,
select() constructs, etc., all standardize on a single keyword
argument/attribute name:  "bind".  "bind" in all cases may receive an Engine
or Connection as its argument (known as a connectable).  In the case of
MetaData, the "bind" attribute on the object itself is also assignable,
which binds the MetaData to the connectable.  While all the previous
attributes and keyword arguments remain in 0.3.9, such as "engine",
"bind_to", "connectable", etc., these are removed in 0.4.  So once your
applications are stable on 0.3.9, begin changing these keywords and
attributes to be named "bind".

    - The generative interface of Query is now the standard.  All of the old
select/get_by methods are still present, as they will remain in 0.4 in a
deprecated state.  However, 90% of 0.4's Query functionality is now
available in 0.3.9, and the Data Mapping documentation discusses this
interface exclusively, addressing many common tasks that have historically
been mysterious to many users, such as joining, selecting multiple
entities/columns, and using string-based criterion or full text queries in
place of constructed expressions.  The improvements in this API, from a
functional and usage standpoint as well as how it's presented in the
documentation, are very significant.  Check out the docs at
http://www.sqlalchemy.org/docs/datamapping.html#datamapping_query .

    - MetaData is now pickleable.  This was a very small change from a
technical point of view, but from an operational point of view, pickling a
MetaData object and storing it in a file should be the new way going forward
to deal with applications which need to reflect large sets of tables every
time they start up.  If your MetaData is bound to an engine, just reattach
the current engine to your unpickled MetaData using metadata.bind = engine.

    - DynamicMetaData is now ThreadLocalMetaData (the old name remains for
compatibility).  This is to ensure that its purpose is clearly understood.
If you only need to bind an engine to a MetaData after the MetaData is
already defined, the regular MetaData does that.

    - Similarly, BoundMetaData is just MetaData.  Theres no difference
between the two.  The old name remains for compatibility.

    - Using polymorphic, joined-table inheritance ?  Forget about
polymorphic_union(), just join all the tables together using outerjoin().
In 0.4, even the select_table argument becomes optional.

The changelog for SQLAlchemy 0.3.9 is available at
http://www.sqlalchemy.org/CHANGES .  Download links 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to