delta/python-packages/sqlalchemy.git/test/orm, branch pr/99 github.com: zzzeek/sqlalchemy.git - use new Or() directive to test for both SQL variants here, which can vary 2014-06-22T00:27:19+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-06-22T00:27:19+00:00 20e64ad6b8bd08b966196388d0f353c53827bdbb based on hash ordering of the ClassManager 
based on hash ordering of the ClassManager
- Additional checks have been added for the case where an inheriting 2014-06-20T22:47:28+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-06-20T22:47:28+00:00 a1bbf3a005677c1371b02c54343f5407747e336d mapper is implicitly combining one of its column-based attributes with that of the parent, where those columns normally don't necessarily share the same value. This is an extension of an existing check that was added via :ticket:`1892`; however this new check emits only a warning, instead of an exception, to allow for applications that may be relying upon the existing behavior. fixes #3042 
mapper is implicitly combining one of its column-based attributes
with that of the parent, where those columns normally don't necessarily
share the same value.  This is an extension of an existing check that
was added via :ticket:`1892`; however this new check emits only a
warning, instead of an exception, to allow for applications that may
be relying upon the existing behavior.
fixes #3042
- Modified the behavior of :func:`.orm.load_only` such that primary key 2014-06-12T15:47:50+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-06-12T15:47:50+00:00 33cb84945f5277a3cf090b73b218abc583d292fc columns are always added to the list of columns to be "undeferred"; otherwise, the ORM can't load the row's identity. Apparently, one can defer the mapped primary keys and the ORM will fail, that hasn't been changed. But as load_only is essentially saying "defer all but X", it's more critical that PK cols not be part of this deferral. fixes #3080 
columns are always added to the list of columns to be "undeferred";
otherwise, the ORM can't load the row's identity.   Apparently,
one can defer the mapped primary keys and the ORM will fail, that
hasn't been changed.  But as load_only is essentially saying
"defer all but X", it's more critical that PK cols not be part of this
deferral. fixes #3080
- Related to :ticket:`3060`, an adjustment has been made to the unit 2014-05-30T05:32:53+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-05-30T05:32:53+00:00 69dbcdd0ebf8de81643c038276fcc822a7b0bd0b of work such that loading for related many-to-one objects is slightly more aggressive, in the case of a graph of self-referential objects that are to be deleted; the load of related objects is to help determine the correct order for deletion if passive_deletes is not set. - revert the changes to test_delete_unloaded_m2o, these deletes do in fact need to occur in the order of the two child objects first. 
of work such that loading for related many-to-one objects is slightly
more aggressive, in the case of a graph of self-referential objects
that are to be deleted; the load of related objects is to help
determine the correct order for deletion if passive_deletes is
not set.
- revert the changes to test_delete_unloaded_m2o, these deletes do in fact
need to occur in the order of the two child objects first.
- add a new assertsql construct "Or", so that we can test for a UOW flush 2014-05-30T04:21:11+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-05-30T04:21:11+00:00 2c8689fd141c278a7bbc250087e553b76a515bc6 that might take one of multiple directions; apply this to test_delete_unloaded_m2o which is now illustrating multiple paths due to #3060/#3061, though still doing the right thing. 
that might take one of multiple directions; apply this to test_delete_unloaded_m2o
which is now illustrating multiple paths due to #3060/#3061, though still doing the
right thing.
- Adjustment to attribute mechanics concerning when a value is 2014-05-29T23:54:51+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-05-29T23:54:51+00:00 752f2e0fc8dec13e313a00f7c9720d24d21429ed implicitly initialized to None via first access; this action, which has always resulted in a population of the attribute, now emits an attribute event just like any other attribute set operation and generates the same kind of history as one. Additionally, many mapper internal operations will no longer implicitly generate these "None" values when various never-set attributes are checked. These are subtle behavioral fixes to attribute mechanics which provide a better solution to the problem of :ticket:`3060`, which also involves recognition of attributes explicitly set to ``None`` vs. attributes that were never set. fixes #3061 
implicitly initialized to None via first access; this action,
which has always resulted in a population of the attribute,
now emits an attribute event just like any other attribute set
operation and generates the same kind of history as one.  Additionally,
many mapper internal operations will no longer implicitly generate
these "None" values when various never-set attributes are checked.
These are subtle behavioral fixes to attribute mechanics which provide
a better solution to the problem of :ticket:`3060`, which also
involves recognition of attributes explicitly set to ``None``
vs. attributes that were never set.
fixes #3061
- Fixed a few edge cases which arise in the so-called "row switch" 2014-05-29T00:01:21+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-05-29T00:01:21+00:00 bc08ee9029258b23171bb67e191452e6c739c597 scenario, where an INSERT/DELETE can be turned into an UPDATE. In this situation, a many-to-one relationship set to None, or in some cases a scalar attribute set to None, may not be detected as a net change in value, and therefore the UPDATE would not reset what was on the previous row. This is due to some as-yet unresovled side effects of the way attribute history works in terms of implicitly assuming None isn't really a "change" for a previously un-set attribute. See also :ticket:`3061`. fixes #3060 
scenario, where an INSERT/DELETE can be turned into an UPDATE.
In this situation, a many-to-one relationship set to None, or
in some cases a scalar attribute set to None, may not be detected
as a net change in value, and therefore the UPDATE would not reset
what was on the previous row.   This is due to some as-yet
unresovled side effects of the way attribute history works in terms
of implicitly assuming None isn't really a "change" for a previously
un-set attribute.  See also :ticket:`3061`. fixes #3060
- Fixed bug in subquery eager loading where a long chain of 2014-05-25T17:45:32+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-05-25T17:45:32+00:00 95b10c4e8e59cf2509ba5d90a03341d74f93d164 eager loads across a polymorphic-subclass boundary in conjunction with polymorphic loading would fail to locate the subclass-link in the chain, erroring out with a missing property name on an :class:`.AliasedClass`. fixes #3055 
eager loads across a polymorphic-subclass boundary in conjunction
with polymorphic loading would fail to locate the subclass-link in the
chain, erroring out with a missing property name on an
:class:`.AliasedClass`. fixes #3055
- fix typos in test 2014-05-24T18:54:07+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-05-24T18:54:07+00:00 6126caec447f98801f3ea7cf045ca807a4537a4d - restore __len__ to identity map 
- restore __len__ to identity map
- more tests, including backend tests 2014-05-16T19:33:39+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-05-16T19:33:39+00:00 81959af6d37be503a13ce9c53317d443e14ae570 - implement for SQL server, use window functions when simple limit/offset not available 
- implement for SQL server, use window functions when simple limit/offset not available