True, defaults that are generated during an INSERT
or UPDATE operation are post-fetched immediately,
instead of being deferred until later. This mimics
the old 0.3 behavior.
(such as PickleTypes)
- added a more descriptive error message when flushing on a
relation() that has non-locally-mapped columns in its primary or
secondary join condition
to a collection-based attribute which already had pending changes
would generate incorrect history [ticket:922]
- fixed delete-orphan cascade bug whereby setting the same
object twice to a scalar attribute could log it as an orphan
[ticket:925]
- generative select.order_by(None) / group_by(None) was not managing to
reset order by/group by criterion, fixed [ticket:924]
which falls back to "deferred" loading of inheriting tables
- the "columns" collection on a mapper/mapped class (i.e. 'c')
is against the mapped table, not the select_table in the
case of polymorphic "union" loading (this shouldn't be
noticeable)
which are later added via add_property(). This commonly includes
backrefs. (i.e. you can make synonyms for backrefs without
worrying about the order of operations) [ticket:919]
deprecated until 0.5. The "upgrading" behavior of String to Text
when no length is present is also deprecated until 0.5; will issue a
warning when used for CREATE TABLE statements (String with no length
for SQL expression purposes is still fine) [ticket:912]
more than once in the unitofwork.new collection; most typically
reproduced when using a combination of inheriting mappers and
ScopedSession.mapper, as the multiple __init__ calls per instance
could save() the object with distinct _state objects
query.yield_per(<number of rows>) and evaluate the Query in an
iterative context; every collection of N rows will be packaged up
and yielded. Use this method with extreme caution since it does
not attempt to reconcile eagerly loaded collections across
result batch boundaries, nor will it behave nicely if the same
instance occurs in more than one batch. This means that an eagerly
loaded collection will get cleared out if it's referenced in more than
one batch, and in all cases attributes will be overwritten on instances
that occur in more than one batch.
Mike Bayer