and the entire related system of alternate
class implementation is now moved out
to sqlalchemy.ext.instrumentation. This is
a seldom used system that adds significant
complexity and overhead to the mechanics of
class instrumentation. The new architecture
allows it to remain unused until
InstrumentationManager is actually imported,
at which point it is bootstrapped into
the core.
reflection" system has been moved into the
declarative extension itself, using the
new DeferredReflection class. This
class is now tested with both single
and joined table inheritance use cases.
[ticket:2485]
- [bug] The autoload_replace flag on Table,
when False, will cause any reflected foreign key
constraints which refer to already-declared
columns to be skipped, assuming that the
in-Python declared column will take over
the task of specifying in-Python ForeignKey
or ForeignKeyConstraint declarations.
provides the functionality of query.with_polymorphic()
in a standalone form. It can be applied to any
entity within a query, including as the target
of a join in place of the "of_type()" modifier.
[ticket:2333]
- redo a large portion of the inheritance docs in terms
of declarative, new with_polymorphic() function
- upgrade examples/inheritance/polymorph, rename to "joined"
in Beaker example to pull bindparams from the
fully compiled statement, as a quick means
to get everything including subqueries in the
columns clause, etc.
example to support single-table inheritance,
multiple calls to prepare(), tables that
are present in alternate schemas,
establishing only a subset of classes
as reflected.
to not rely upon SQLAlchemy test libs,
nosetests must be run from within
examples/versioning to get around setup.cfg
breaking it.
- Tweak to examples/versioning to pick the
correct foreign key in a multi-level
inheritance situation.
Session argument "query_cls" as a constructor argument,
to enable further subclassing of ShardedQuery.
[ticket:2090]
- The Beaker caching example allows a "query_cls" argument
to the query_callable() function. [ticket:2090]
- streamline interfaces, get Mutable/MutableComposite to be as minimal
in usage as possible
- docs for mutable, warnings regrarding mapper events being global
- move MutableType/mutable=True outwards, move orm tests to its
own module, note in all documentation
- still need more events/tests for correct pickling support of
composites, mutables. in the case of composites its needed
even without mutation. see [ticket:2009]
synonyms for relationships might just be taken out altogether, since they aren't
documented and are of little use. a plain proxying descriptor, combined with
attribute-based usage with Query (as opposted to naming it by string)
can do the same thing more simply.
- add event support to composites, change the model around so that the composite
is generated at the point of load.
- add a recipe for tracking mutations on composites. will probably make both
of these mutations examples into extensions since they're intricate, should
have a lot of test coverage, and what they need to do is fairly straightforward.
Will use metaclasses so that no extra userland step is needed beyond usage
of the type.
- simplify listen_for_events example with new system
- add "propagate", "retval", "raw" flags to attribute events. this solves the "return value"
issue as well as the "subclass" issue.
- begin thinking about event removal. Each listen() method will have a corresponding remove().
Custom listen() methods will have to package all the info onto the event function that is needed
to remove its state.
- attrbutes.py splits into attribtes.py and instrumentation.py
- all the various Event subclasses go into events.py modules
- some ideas for orm events
- move *Extension out to deprecated_interfaces