SQLAlchemy 0.3.2 review

SQLAlchemy is a SQL toolkit and object relational mapper for Python. The Python SQL toolkit and Object Relational Mapper that give

License: MIT/X Consortium License File size: 0K Developer: Michael Bayer

0

SQLAlchemy is a SQL toolkit and object relational mapper for Python.

The Python SQL toolkit and Object Relational Mapper that gives application developers the full power and flexibility of SQL. SQLAlchemy provides a full suite of well known enterprise-level persistence patterns, designed for efficient and high-performing database access, adapted into a simple and Pythonic domain language.

extremely easy to use for all the basic tasks, such as: accessing thread-safe and pooled connections, constructing SQL from Python expressions, finding object instances, and commiting object modifications back to the database.
powerful enough for complicated tasks, such as: eager load a graph of objects and their dependencies via joins; map recursive adjacency structures automatically; map objects to not just tables but to any arbitrary join or select statement; combine multiple tables together to load whole sets of otherwise unrelated objects from a single result set; commit entire graphs of object changes in one step.
built to conform to what DBAs demand, including the ability to swap out generated SQL with hand-optimized statements, full usage of bind parameters for all literal values, fully transactionalized and consistent updates using Unit of Work.
modular. Different parts of SQLAlchemy can be used independently of the rest, including the connection pool, SQL construction, and ORM. SQLAlchemy is constructed in an open style that allows plenty of customization, with an architecture that supports custom datatypes, custom SQL extensions, and ORM plugins which can augment or extend mapping functionality.

SQLAlchemy's Philosophy:

SQL databases behave less and less like object collections the more size and performance start to matter; object collections behave less and less like tables and rows the more abstraction starts to matter. SQLAlchemy aims to accomodate both of these principles.
Your classes aren't tables, and your objects aren't rows. Databases aren't just collections of tables; they're relational algebra engines. You don't have to select from just tables, you can select from joins, subqueries, and unions. Database and domain concepts should be visibly decoupled from the beginning, allowing both sides to develop to their full potential.
For example, table metadata (objects that describe tables) are declared distinctly from the classes theyre designed to store. That way database relationship concepts don't interfere with your object design concepts, and vice-versa; the transition from table-mapping to selectable-mapping is seamless; a class can be mapped against the database in more than one way. SQLAlchemy provides a powerful mapping layer that can work as automatically or as manually as you choose, determining relationships based on foreign keys or letting you define the join conditions explicitly, to bridge the gap between database and domain.

SQLAlchemy's Advantages:

The Unit Of Work system organizes pending CRUD operations into queues and commits them all in one batch. It then performs a topological "dependency sort" of all items to be committed and deleted and groups redundant statements together. This produces the maxiumum efficiency and transaction safety, and minimizes chances of deadlocks. Modeled after Fowler's "Unit of Work" pattern as well as Java Hibernate.
Function-based query construction allows boolean expressions, operators, functions, table aliases, selectable subqueries, create/update/insert/delete queries, correlated updates, correlated EXISTS clauses, UNION clauses, inner and outer joins, bind parameters, free mixing of literal text within expressions, as little or as much as desired. Query-compilation is vendor-specific; the same query object can be compiled into any number of resulting SQL strings depending on its compilation algorithm.
Database mapping and class design are totally separate. Persisted objects have no subclassing requirement (other than 'object') and are POPO's : plain old Python objects. They retain serializability (pickling) for usage in various caching systems and session objects. SQLAlchemy "decorates" classes with non-intrusive property accessors to automatically log object creates and modifications with the UnitOfWork engine, to lazyload related data, as well as to track attribute change histories.
Custom list classes can be used with eagerly or lazily loaded child object lists, allowing rich relationships to be created on the fly as SQLAlchemy appends child objects to an object attribute.
Composite (multiple-column) primary keys are supported, as are "association" objects that represent the middle of a "many-to-many" relationship.
Self-referential tables and mappers are supported. Adjacency list structures can be created, saved, and deleted with proper cascading, with no extra programming.
Data mapping can be used in a row-based manner. Any bizarre hyper-optimized query that you or your DBA can cook up, you can run in SQLAlchemy, and as long as it returns the expected columns within a rowset, you can get your objects from it. For a rowset that contains more than one kind of object per row, multiple mappers can be chained together to return multiple object instance lists from a single database round trip.
The type system allows pre- and post- processing of data, both at the bind parameter and the result set level. User-defined types can be freely mixed with built-in types. Generic types as well as SQL-specific types are available.

Requirements:
Python

What's New in This Release:
- major connection pool bug fixed. fixes MySQL out of sync
errors, will also prevent transactions getting rolled back
accidentally in all DBs [ticket:387]
- major speed enhancements vs. 0.3.1, to bring speed
back to 0.2.8 levels
- made conditional dozens of debug log calls that were
time-intensive to generate log messages
- fixed bug in cascade rules whereby the entire object graph
could be unnecessarily cascaded on the save/update cascade
- various speedups in attributes module
- identity map in Session is by default *no longer weak referencing*.
to have it be weak referencing, use create_session(weak_identity_map=True)
fixes [ticket:388]
- MySQL detects errors 2006 (server has gone away) and 2014
(commands out of sync) and invalidates the connection on which it occured.
- MySQL bool type fix: [ticket:307]
- postgres reflection fixes: [ticket:349] [ticket:382]
- added keywords for EXCEPT, INTERSECT, EXCEPT ALL, INTERSECT ALL
[ticket:247]
- assign_mapper in assignmapper extension returns the created mapper
[changeset:2110]
- added label() function to Select class, when scalar=True is used
to create a scalar subquery
i.e. "select x, y, (select max(foo) from table) AS foomax from table"
- added onupdate and ondelete keyword arguments to ForeignKey; propigate
to underlying ForeignKeyConstraint if present. (dont propigate in the
other direction, however)
- fix to session.update() to preserve "dirty" status of incoming object
- sending a selectable to an IN via the in_() function no longer creates
a "union" out of multiple selects; only one selectable to a the in_() function
is allowed now (make a union yourself if union is needed)
- improved support for disabling save-update cascade via cascade="none" etc.
- added "remote_side" argument to relation(), used only with self-referential
mappers to force the direction of the parent/child relationship. replaces
the usage of the "foreignkey" parameter for "switching" the direction.
"foreignkey" argument is deprecated for all uses and will eventually
be replaced by an argument dedicated to ForeignKey specification on mappers.