- Added "map_to()" method to SqlSoup, which is a "master"
method which accepts explicit arguments for each aspect of
the selectable and mapping, including a base class per
mapping. [ticket:1975]
- Mapped selectables used with the map(), with_labels(),
join() methods no longer put the given argument into the
internal "cache" dictionary. Particularly since the
join() and select() objects are created in the method
itself this was pretty much a pure memory leaking behavior.
reverse order of which they were added to the property. A
typical effect of this is that the ".id" attribute on a
joined-inheritance subclass, where both parent/child tables
name the PK column ".id", will reference the ".id" column of
the child table, not the parent, thus allowing join conditions
and such to be constructed more intuitively. This is a
behavior change for some joined-table inheritance queries.
[ticket:1892]
- it's now an error condition to map to a join where multiple
same-named columns from each table combine themselves
implicitly. An explicit mention in the "properties" dictionary
should be specified, using a list of columns, or
column_property(*cols) with declarative. [ticket:1892]
logic when columns are present in a joined subclass with an attribute name different
than the column name itself [ticket:1931]
- add coverage to verify that we need to check (obj.name or name) when
deciding if a Column from a mixin should be added to the mapped table
correctly to a single-table inheritance scheme where
the attribute name is different than that of the column.
[ticket:1930]. Note [ticket:1931] which is the same
issue for joined inh, not yet resolved.
with declarative is sqlalchemy.ext.declarative.mapperproperty.
Same thing, but moving there since it is more of a
"marker" that's specific to declararative,
not just an attribute technique. [ticket:1915]
- The exception raised by Session when it is used
subsequent to a subtransaction rollback (which is what
happens when a flush fails in autocommit=False mode) has
now been reworded (this is the "inactive due to a
rollback in a subtransaction" message). In particular,
if the rollback was due to an exception during flush(),
the message states this is the case, and reiterates the
string form of the original exception that occurred
during flush. If the session is closed due to explicit
usage of subtransactions (not very common), the message
just states this is the case.
- The exception raised by Mapper when repeated requests to
its initialization are made after initialization already
failed no longer assumes the "hasattr" case, since
there's other scenarios in which this message gets
emitted, and the message also does not compound onto
itself multiple times - you get the same message for
each attempt at usage. The misnomer "compiles" is being
traded out for "initialize".
to mapper() now accept Column objects as members in
addition to strings. This so that same-named Column
objects, such as those within a join(), can be
disambiguated.
- A warning is now emitted if a mapper is created against a
join or other single selectable that includes multiple
columns with the same name in its .c. collection,
and those columns aren't explictly named as part of
the same or separate attributes (or excluded).
In 0.7 this warning will be an exception. Note that
this warning is not emitted when the combination occurs
as a result of inheritance, so that attributes
still allow being overridden naturally.
[ticket:1896]. In 0.7 this will be improved further.
- The primary_key argument to mapper() can now specify
a series of columns that are only a subset of
the calculated "primary key" columns of the mapped
selectable, without an error being raised. This
helps for situations where a selectable's effective
primary key is simpler than the number of columns
in the selectable that are actually marked as
"primary_key", such as a join against two
tables on their primary key columns [ticket:1896].
mapper property attribute, it will be called to get the
actual attribute value during initialization. Currently,
there's no advantage to using @classproperty on a column
or relationship attribute of a declarative class that
isn't a mixin - evaluation is at the same time as if
@classproperty weren't used. But here we at least allow
it to function as expected.
- docs for column_property() with declarative
- mixin docs in declarative made more clear - mixins
are optional - each subsection starts with, "in *declarative mixins*",
to reduce confusion
any kind of schema/mapping construct from a
declarative mixin, including columns with foreign
keys, relationships, column_property, deferred.
This solves all such issues on declarative mixins.
An error is raised if any MapperProperty subclass
is specified on a mixin without using @classproperty.
[ticket:1751] [ticket:1796] [ticket:1805]
- un-anglicized the declarative docs
when overriding the compilation of a built in
clause construct, so no KeyError is raised if the
user-defined compiler is specific to certain
backends and compilation for a different backend
is invoked. [ticket:1838]
one which is present on a __table__ defined on a
subclass. It cannot, however, define one that is
not present in the __table__, and the error message
here now works. [ticket:1821]
Mike Bayer