| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
| |
a consistent tag
- AUTHORS file
|
| |
|
|
| |
receivers
|
| |
|
|
|
| |
cascade_iterator() should probably not yield the "instance" at all
and only deal in states. 30-40K methods taken off the orm2010 test.
|
| |
|
|
| |
streamline get_history() in any case
|
| | |
|
| |
|
|
| |
- add test coverage for the rare case of noload->lazyload + pickle
|
| |
|
|
|
|
|
| |
registry
- test suite swaps out warnings.warn with warnings.warn_explicit, to solve warnings registry issue
- explicitly disallow functions from inside test.bootstrap, test.lib being interpreted as tests
|
| |
|
|
|
|
|
|
|
|
|
| |
relationships
when "save-update" cascade is disabled, or the target object is otherwise not
present in the session, and collection/scalar changes have taken place. A warning
is emitted describing the type of operation, the target reference, and the relationship
description, stating that the operation will not take place. The operation then doesn't
take place. [ticket:1973]
- clean up test_cascade a little bit, remove cruft
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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".
|
| |
|
|
|
|
|
|
|
|
|
| |
when placed only on the many-to-one side of a
relationship; documentation has been clarified
that passive_updates=False should really be on the
one-to-many side.
- Placing passive_deletes=True on a many-to-one emits
a warning, since you probably intended to put it on
the one-to-many side.
|
| |
|
|
|
|
|
|
|
|
| |
changed to StaleDataError, and descriptive
error messages have been revised to reflect
exactly what the issue is. Both names will
remain available for the forseeable future
for schemes that may be specifying
ConcurrentModificationError in an "except:"
clause.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
another, or vice versa changing the referenced
object by an m2o, where the foreign key is also a
member of the primary key, will now be more
carefully checked during flush if the change in
value of the foreign key on the "many" side is the
result of a change in the primary key of the "one"
side, or if the "one" is just a different object.
In one case, a cascade-capable DB would have
cascaded the value already and we need to look at
the "new" PK value to do an UPDATE, in the other we
need to continue looking at the "old". We now look
at the "old", assuming passive_updates=True,
unless we know it was a PK switch that
triggered the change. [ticket:1856]
|
| |
|
|
|
|
|
|
|
| |
which triggered unnecessarily on expired/unloaded
collections. This load now takes place only if
passive_updates is False and the parent primary
key has changed, or if passive_deletes is False
and a delete of the parent has occurred.
[ticket:1845]
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
approach.
not sure if one-to-many with elaborate self-refs, etc., but we appear to be
as good as we were before.
|
| | |
|
| |
|
|
|
|
|
|
| |
action. for one-to-many, we
have it working the old way still. as usual the huge job is the tests. also I am not yet certain
that post updates can always be a "full mapper" operation, i.e. are never involved in per-state dependencies,
or even if the old approach supports that.
|
| |
|
|
|
|
|
|
|
|
| |
is referenced by parent objects via many-to-one,
without the parent's foreign key value getting
temporarily set to None - this was a function
of the "detect primary key switch" flush handler.
It now ignores objects that are no longer
in the "persistent" state, and the parent's
foreign key identifier is left unaffected.
|
| |
|
|
|
|
|
| |
bi-directional many-to-many relationships, where
two objects made to mutually reference each other
in one flush would fail to insert a row for both
sides. Regression from 0.5. [ticket:1824]
|
| |
|
|
|
| |
that broke updates for bi-directional relationship()
with post_update=True. [ticket:1807]
|
| |
|
|
|
|
|
| |
- with m2m we have to go back to the previous approach of having both sides of
the DP fire off, tracking each pair of objects. history may not be consistently present
in one side or the other
- this revealed a whole lot of issues with self-referential m2m, which are fixed
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- one-to-many relationships now maintain a list of positive
parent-child associations within the flush, preventing
previous parents marked as deleted from cascading a
delete or NULL foreign key set on those child objects,
despite the end-user not removing the child from the old
association. [ticket:1764]
- re-established Preprocess as unique on their arguments,
as they were definitely duped in inheritance scenarios
- added a "memo" feature to UOWTransaction which represents the usual
pattern of using the .attributes collection
- added the test case from [ticket:1081] into perf/
|
| | |
|
| |
|
|
| |
work doesn't occur during per-state usage
|
| |
|
|
| |
preprocess/process down
|
| | |
|
| |
|
|
| |
are established
|
| |
|
|
|
|
| |
pulled into the unit of work at all. this involves dancing around lists
of states, seeing if child objects exist, not adding excessive callcounts
while doing that, etc.
|
| |
|
|
|
|
| |
per-state/proc for this at all.
this greatly reduces unnecessary crap in the UOW for complex models.
|
| |
|
|
|
| |
- some other areas where per-state deps are called and an empty result returned
are still lacking coverage.
|
| | |
|
| |
|
|
|
| |
will be needed overall as missing dependency rules lead
to subtle bugs pretty easily
|
| | |
|
| | |
|
| |
|
|
|
| |
- now running on the full suite of tests. unsurprisingly, it appears
there are subtle self-referential issues causing many tests to fail.
|
| |
|
|
|
|
| |
not execute at all when a one-to-many is present on the reverse side.
- OneToMany can establish a state as "listonly" when passive_updates are enabled
and the change is due to key switch.
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
- fix some side-effect-dependent behaviors in uow. we can now
unconditionally remove "disabled" actions without rewriting
|
| | | |
|
| | |
| |
| |
| | |
procesing overhead.
|
| | |
| |
| |
| |
| |
| | |
deps. the pattern here
is more data needed for each tweak.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
- we do need dependencies between an object and its dep when the other object
has no save or delete pending. the other object
like before isn't needed, but right now we make the dependency just 'None',
and it gets thrown away.
|