to :class:`.Engine`. This method works similarly to
:class:`.Connection.execution_options` in that it creates
a copy of the parent object which will refer to the new
set of options. The method can be used to build
sharding schemes where each engine shares the same
underlying pool of connections. The method
has been tested against the horizontal shard
recipe in the ORM as well.
become an externally usable package but still remains within the main sqlalchemy parent package.
in this system, we use kind of an ugly hack to get the noseplugin imported outside of the
"sqlalchemy" package, while still making it available within sqlalchemy for usage by
third party libraries.
between a @declared_attr Column and a
directly-defined Column on a mixin. In both
cases, the Column will be applied to the
declared class' table, but not to that of a
joined inheritance subclass. Previously,
the directly-defined Column would be placed
on both the base and the sub table, which isn't
typically what's desired. [ticket:2565]
CREATE TABLE that provides access to the render for each
Column individually, by constructing a @compiles
function against the new schema.CreateColumn
construct. [ticket:2463]
single-inheritance declarative subclasses,
with or without using a mixin, can be resolved
using a new @declared_attr usage described
in the documentation. [ticket:2472]
declared on a single-table inheritance subclass
up to the parent class' table, when the parent
class is itself mapped to a join() or select()
statement, directly or via joined inheritane,
and not just a Table. [ticket:2549]
the vast majority of file lines are spent on documentation, which moves
into package __init__. The core declarative idea lives in base and
is back down to its originally low size of under 500 lines. The various
helpers and such move into api.py, and the full span of string lookup
moves into a new module clsregistry. the rest of declarative only
refers to two functions in clsregistry in three places inside of base.
- [feature] Declarative now maintains a registry
of classes by string name as well as by full
module-qualified name. Multiple classes with the
same name can now be looked up based on a module-qualified
string within relationship(). Simple class name
lookups where more than one class shares the same
name now raises an informative error message.
[ticket:2338]
- lots of tests to ensure the new weak referencing memory management
is maintained by the new class registry system. this ticket was
served very well by waiting to do #2526 first, else this would
have needed to be rewritten anyway.
- modify inspection system:
1. raise a new exception for any case where the inspection
context can't be returned. this supersedes the "not mapped"
errors.
2. don't configure mappers on a mapper inspection. this allows
the inspectors to be used during mapper config time. instead,
the mapper configures on "with_polymorphic_selectable" now,
which is needed for all queries
- add a bunch of new "is_XYZ" attributes to inspectors
- finish making the name change of "compile" -> "configure", for some reason
this was only done partially
AbstractConcreteBase helper where the "type"
attribute from the superclass would not
be overridden on the subclass to produce the
"reserved for base" error message, instead placing
a do-nothing attribute there. This was inconsistent
vs. using ConcreteBase as well as all the behavior
of classical concrete mappings, where the "type"
column from the polymorphic base would be explicitly
disabled on subclasses, unless overridden
explicitly.
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.
whereby the precedence of columns
in a joined-table, composite
column (typically for id) would fail to
be correct if the columns contained
names distinct from their attribute
names. This would cause things like
primaryjoin conditions made against the
entity attributes to be incorrect. Related
to [ticket:1892] as this was supposed
to be part of that, this is [ticket:2491].
Also in 0.7.8.
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.
- resolved some serious speed hits I missed, we need to ensure
only deannotated columns are used in the local/remote collections and soforth
so that hash lookups against mapped columns don't dig into __eq__()
- fix some other parity mismatches regarding stuff from [ticket:2453],
including finding another case where _deep_annotate() was doing the wrong thing,
new tests.
- [feature] Major rewrite of relationship()
internals now allow join conditions which
include columns pointing to themselves
within composite foreign keys. A new
API for very specialized primaryjoin conditions
is added, allowing conditions based on
SQL functions, CAST, etc. to be handled
by placing the annotation functions
remote() and foreign() inline within the
expression when necessary. Previous recipes
using the semi-private _local_remote_pairs
approach can be upgraded to this new
approach. [ticket:1401]
have enough of its state set up to work
correctly within the unpickle() event established
by the mutable object extension, if the object
needed ORM attribute access within
__eq__() or similar. [ticket:2362]
against ORM-level column could be treated as
a distinct entity when producing certain
kinds of joined-inh joins. [ticket:2316]
- [bug] related to [ticket:2316], made some
adjustments to the change from [ticket:2261]
regarding the "from" list on a select(). The
_froms collection is no longer memoized, as this
simplifies various use cases and removes the
need for a "warning" if a column is attached
to a table after it was already used in an
expression - the select() construct will now
always produce the correct expression.
There's probably no real-world
performance hit here; select() objects are
almost always made ad-hoc, and systems that
wish to optimize the re-use of a select()
would be using the "compiled_cache" feature.
A hit which would occur when calling select.bind
has been reduced, but the vast majority
of users shouldn't be using "bound metadata"
anyway :).
Mike Bayer