added, which proxies down to the ``.info`` attribute on either the :class:`.schema.Column` object if directly present, or the :class:`.MapperProperty` otherwise. The full behavior is documented and ensured by tests to remain stable. [ticket:2675]
mapper configuration; will now test for name conflicts on superclasses and subclasses, in addition to the current mapper, as these conflicts break things just as much. This is new for 0.8, but see below for a warning that will also be triggered in 0.7.11. - Improved the error message emitted when a "backref loop" is detected, that is when an attribute event triggers a bidirectional assignment between two other attributes with no end. This condition can occur not just when an object of the wrong type is assigned, but also when an attribute is mis-configured to backref into an existing backref pair. Also in 0.7.11. - A warning is emitted when a MapperProperty is assigned to a mapper that replaces an existing property, if the properties in question aren't plain column-based properties. Replacement of relationship properties is rarely (ever?) what is intended and usually refers to a mapper mis-configuration. Also in 0.7.11. [ticket:2674]
- paths now store Mapper + MapperProperty now instead of string key, so that the parent mapper for the property is known, supports same-named properties on multiple subclasses - the Mapper within the path is now always relevant to the property to the right of it. PathRegistry does the translation now, instead of having all the outside users of PathRegistry worry about it, to produce a path that is much more consistent. Paths are now consistent with mappings in all cases. Special logic to get at "with_polymorphic" structures and such added also. - AliasedClass now has two modes, "use_mapper_path" and regular; "use_mapper_path" is for all those situations where we put an AliasedClass in for a plain class internally, and want it to "path" with the plain mapper. - The AliasedInsp is now the first class "entity" for an AliasedClass, and is passed around internally and used as attr._parententity and such. it is the AliasedClass analogue for Mapper.
1. all Comparators now have "parent" which is always the parent mapper or AliasedClass instance 2. only RelationshipProperty.Comparator has "mapper" now, which is the target mapper 3. The names "parententity" and "parentmapper" are underscored also improved the message with the "neither comparator nor instruentedattribute...." to include the classname + attribute name
to help with generative building. Also slight adjustment
regarding how SS "correlates" columns; the new methodology
no longer applies meaning to the underlying
Table column being selected. This improves
some fairly esoteric situations, and the logic
that was there didn't seem to have any purpose.
- [feature] Some support for auto-rendering of a
relationship join condition based on the mapped
attribute, with usage of core SQL constructs.
E.g. select([SomeClass]).where(SomeClass.somerelationship)
would render SELECT from "someclass" and use the
primaryjoin of "somerelationship" as the WHERE
clause. This changes the previous meaning
of "SomeClass.somerelationship" when used in a
core SQL context; previously, it would "resolve"
to the parent selectable, which wasn't generally
useful. Related to [ticket:2245].
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.
column_property(), relationship(), composite(). All MapperProperty classes have an auto-creating .info dict available overall.
the `getitem` operator, i.e. the bracket operator in Python. This is used at first to provide index and slice behavior to the Postgresql ARRAY type, and also provides a hook for end-user definition of custom __getitem__ schemes which can be applied at the type level as well as within ORM-level custom operator schemes. Note that this change has the effect that descriptor-based __getitem__ schemes used by the ORM in conjunction with synonym() or other "descriptor-wrapped" schemes will need to start using a custom comparator in order to maintain this behavior. - [feature] postgresql.ARRAY now supports indexing and slicing. The Python [] operator is available on all SQL expressions that are of type ARRAY; integer or simple slices can be passed. The slices can also be used on the assignment side in the SET clause of an UPDATE statement by passing them into Update.values(); see the docs for examples. - [feature] Added new "array literal" construct postgresql.array(). Basically a "tuple" that renders as ARRAY[1,2,3].