for UPDATE statements in the ORM (e.g. :ref:`feature_updatemany`)
would break on Postgresql and other RETURNING backends
when using server-side version generation
schemes, as the server side value is retrieved via RETURNING which
is not supported with executemany.
fixes#3556
feature would cause an object's version counter to be incremented
when there was no net change to the object's row, but instead an object
related to it via relationship (e.g. typically many-to-one)
were associated or de-associated with it, resulting in an UPDATE
statement that updates the object's version counter and nothing else.
In the use case where the relatively recent "server side" and/or
"programmatic/conditional" version counter feature were used
(e.g. setting version_id_generator to False), the bug could cause an
UPDATE without a valid SET clause to be emitted.
fixes#3465
- an existing state shouldn't need its load_options/load_path updated;
it should maintain those from its original Query source. there's no
tests that check this behavior
to rely upon server generated version identifiers, using triggers
or other database-provided versioning features, by passing the value
``False``. The ORM will use RETURNING when available to immediately
load the new version identifier, else it will emit a second SELECT.
[ticket:2793]
- The ``eager_defaults`` flag of :class:`.Mapper` will now allow the
newly generated default values to be fetched using an inline
RETURNING clause, rather than a second SELECT statement, for backends
that support RETURNING.
- Added a new variant to :meth:`.ValuesBase.returning` called
:meth:`.ValuesBase.return_defaults`; this allows arbitrary columns
to be added to the RETURNING clause of the statement without interfering
with the compilers usual "implicit returning" feature, which is used to
efficiently fetch newly generated primary key values. For supporting
backends, a dictionary of all fetched values is present at
:attr:`.ResultProxy.returned_defaults`.
- add a glossary entry for RETURNING
- add documentation for version id generation, [ticket:867]
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.
access to the cls/self.tables/classes registries
- express orm/_base.py ORMTest in terms of engine/_base.py TablesTest,
factor out common steps into TablesTest, remove AltEngineTest as a
separate class. will further consolidate these base classes
state against that of the database, assuming the mapping
uses version ids and incoming state has a version_id
assigned, and raise StaleDataError if they don't
match. [ticket:2027]
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.
manually, and this will result in an UPDATE
of the row. Versioned UPDATEs and DELETEs
now use the "committed" value of the
version_id_col in the WHERE clause and
not the pending changed value. The
version generator is also bypassed if
manual changes are present on the attribute.
[ticket:1857]
- ensure before_update/after_update called on parent
for collection change
- Usage of version_id_col on a backend that supports
cursor.rowcount for execute() but not executemany() now works
when a delete is issued (already worked for saves, since those
don't use executemany()). For a backend that doesn't support
cursor.rowcount at all, a warning is emitted the same
as with saves. [ticket:1761]
on the given instance first, so that the "refresh-expire"
cascade is propagated. Previously, refresh() was
not affected in any way by the presence of "refresh-expire"
cascade. This is a change in behavior versus that
of 0.6beta2, where the "lockmode" flag passed to refresh()
would cause a version check to occur. Since the instance
is first expired, refresh() always upgrades the object
to the most recent version.
- The 'refresh-expire' cascade, when reaching a pending object,
will expunge the object if the cascade also includes
"delete-orphan", or will simply detach it otherwise.
[ticket:1754]
relationship(), to eliminate confusion over the relational
algebra term. relation() however will remain available
in equal capacity for the foreseeable future. [ticket:1740]
INSERT and DELETE replaced by an UPDATE, to fail when
version_id_col was in use. [ticket:1692]
- Added "version_id_generator" argument to Mapper, this is a
callable that, given the current value of the "version_id_col",
returns the next version number. Can be used for alternate
versioning schemes such as uuid, timestamps. [ticket:1692]
Mike Bayer