This release includes a bunch of architectural enhancements that  
didn't make it into 0.5.0, a handful of bug fixes, and one bigger bug  
fix for a potential memory leak in Query.   Upgrading is not mandatory  
but is recommended.

Changes of note include:

   - the memory leak bug is specifically if you said something like s  
= select([...]); query.join((s, Foo.bar)).  The select() construct was  
being placed into a cache from which it would never be cleared.   The  
caching mechanism within the join logic has been removed as it didn't  
seem to have much performance benefit.  If people notice their  
applications have become slower compared to 0.5.0, please let me know   
- I wasn't able to observe any degradation in performance.
   - we've finally deprecated the Session methods clear()/save()/ 
update()/save_or_update() so those will raise deprecation warnings now.
   - the behavior of concrete inheritance in particular has been  
enhanced, while this is a less common use case people who are using  
this feature should let me know how the new code works out.
   - Declarative includes much nicer support for single-table  
inheritance.  Table columns can be specified on subclasses where they  
will be added to the parent class' table, but only mapped on the  
subclass.   You can do this with classical mapper usage too but it  
usually requires explicit usage of exclude_properties to keep columns  
local to the class they are relevant towards - the declarative  
approach takes care of it for you.
   - the internal approach to triggering mapper compilation has been  
simplified.   the only noticeable effect here should be that you can  
create expressions from class bound attributes without mapper  
compilation occuring, which should help significantly with declarative  
(i.e. when you say primaryjoin=id==OtherClass.someid, no mapper  
compile will be triggered).

Download SQLAlchemy 0.5.1 at:  http://www.sqlalchemy.org/download.html

0.5.1
========

- orm
     - Removed an internal join cache which could potentially leak
       memory when issuing query.join() repeatedly to ad-hoc
       selectables.

     - The "clear()", "save()", "update()", "save_or_update()"
       Session methods have been deprecated, replaced by
       "expunge_all()" and "add()".  "expunge_all()" has also
       been added to ScopedSession.

     - Modernized the "no mapped table" exception and added a more
       explicit __table__/__tablename__ exception to declarative.

     - Concrete inheriting mappers now instrument attributes which
       are inherited from the superclass, but are not defined for
       the concrete mapper itself, with an InstrumentedAttribute that
       issues a descriptive error when accessed. [ticket:1237]

     - Added a new `relation()` keyword `back_populates`. This
       allows configuation of backreferences using explicit
       relations. [ticket:781] This is required when creating
       bidirectional relations between a hierarchy of concrete
       mappers and another class. [ticket:1237]

     - Test coverage added for `relation()` objects specified on
       concrete mappers. [ticket:1237]

     - Query.from_self() as well as query.subquery() both disable
       the rendering of eager joins inside the subquery produced.
       The "disable all eager joins" feature is available publically
       via a new query.enable_eagerloads() generative. [ticket:1276]

     - Added a rudimental series of set operations to Query that
       receive Query objects as arguments, including union(),
       union_all(), intersect(), except_(), insertsect_all(),
       except_all().  See the API documentation for
       Query.union() for examples.

     - Fixed bug that prevented Query.join() and eagerloads from
       attaching to a query that selected from a union or aliased union.

     - A short documentation example added for bidirectional
       relations specified on concrete mappers. [ticket:1237]

     - Mappers now instrument class attributes upon construction
       with the final InstrumentedAttribute object which remains
       persistent. The `_CompileOnAttr`/`__getattribute__()`
       methodology has been removed. The net effect is that
       Column-based mapped class attributes can now be used fully
       at the class level without invoking a mapper compilation
       operation, greatly simplifying typical usage patterns
       within declarative. [ticket:1269]

     - ColumnProperty (and front-end helpers such as ``deferred``) no
       longer ignores unknown **keyword arguments.

     - Fixed a bug with the unitofwork's "row switch" mechanism,
       i.e. the conversion of INSERT/DELETE into an UPDATE, when
       combined with joined-table inheritance and an object
       which contained no defined values for the child table where
       an UPDATE with no SET clause would be rendered.

     - Using delete-orphan on a many-to-many relation is deprecated.
       This produces misleading or erroneous results since SQLA does
       not retrieve the full list of "parents" for m2m.  To get delete- 
orphan
       behavior with an m2m table, use an explcit association class
       so that the individual association row is treated as a parent.
       [ticket:1281]

     - delete-orphan cascade always requires delete cascade.  Specifying
       delete-orphan without delete now raises a deprecation warning.
       [ticket:1281]

- sql
     - Improved the methodology to handling percent signs in column
       names from [ticket:1256].  Added more tests.  MySQL and
       Postgres dialects still do not issue correct CREATE TABLE
       statements for identifiers with percent signs in them.

- schema
     - Index now accepts column-oriented InstrumentedAttributes
       (i.e. column-based mapped class attributes) as column
       arguments. [ticket:1214]

     - Column with no name (as in declarative) won't raise a
       NoneType error when it's string output is requsted
       (such as in a stack trace).

     - Fixed bug when overriding a Column with a ForeignKey
       on a reflected table, where derived columns (i.e. the
       "virtual" columns of a select, etc.) would inadvertently
       call upon schema-level cleanup logic intended only
       for the original column. [ticket:1278]

- declarative
     - Can now specify Column objects on subclasses which have no
       table of their own (i.e. use single table inheritance).
       The columns will be appended to the base table, but only
       mapped by the subclass.

     - For both joined and single inheriting subclasses, the subclass
       will only map those columns which are already mapped on the
       superclass and those explicit on the subclass.  Other
       columns that are present on the `Table` will be excluded
       from the mapping by default, which can be disabled
       by passing a blank `exclude_properties` collection to the
       `__mapper_args__`.  This is so that single-inheriting
       classes which define their own columns are the only classes
       to map those columns.   The effect is actually a more organized
       mapping than you'd normally get with explicit `mapper()`
       calls unless you set up the `exclude_properties` arguments
       explicitly.

     - It's an error to add new Column objects to a declarative class
       that specified an existing table using __table__.

- mysql
     - Added the missing keywords from MySQL 4.1 so they get escaped
       properly.

- mssql
     - Corrected handling of large decimal values with more robust
       tests. Removed string manipulation on floats. [ticket:1280]

     - Modified the do_begin handling in mssql to use the Cursor not
       the Connection so it is DBAPI compatible.

     - Corrected SAVEPOINT support on adodbapi by changing the
       handling of savepoint_release, which is unsupported on mssql.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to [email protected]
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