| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modified the change made to the ORM update/delete evaluator in
:ticket:`3366` such that if an unmapped column expression is present
in the update or delete, if the evaluator can match its name to the
mapped columns of the target class, a warning is emitted, rather than
raising UnevaluatableError. This is essentially the pre-1.2 behavior,
and is to allow migration for applications that are currently relying
upon this pattern. However, if the given attribute name cannot be
matched to the columns of the mapper, the UnevaluatableError is
still raised, which is what was fixed in :ticket:`3366`.
Change-Id: I658ed0dbf485b7f8009774f9c12d9912447abd2a
Fixes: #4073
|
| |
|
|
|
|
|
|
| |
Implement rowcount assertions and single row check
for post_update as well as deletes.
Change-Id: I4e5ba7e8747bf0e0b41f569089eb8cdbf064b7a9
Fixes: #4062
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a new class of "rowcount support" for dialects that is specific to
when "RETURNING", which on SQL Server looks like "OUTPUT inserted", is in
use, as the PyODBC backend isn't able to give us rowcount on an UPDATE or
DELETE statement when OUTPUT is in effect. This primarily affects the ORM
when a flush is updating a row that contains server-calcluated values,
raising an error if the backend does not return the expected row count.
PyODBC now states that it supports rowcount except if OUTPUT.inserted is
present, which is taken into account by the ORM during a flush as to
whether it will look for a rowcount.
ORM tests are implicit in existing tests run against PyODBC
Fixes: #4062
Change-Id: Iff17cbe4c7a5742971ed85a4d58660c18cc569c2
|
| |
|
|
|
|
|
|
|
|
| |
Fixed bug involving JSON NULL evaluation logic added in 1.1 as part
of :ticket:`3514` where the logic would not accommodate ORM
mapped attributes named differently from the :class:`.Column`
that was mapped.
Change-Id: I1848afcfb63ad7f074f315d8d3097666069b42be
Fixes: #4031
|
| |
|
|
|
|
|
|
|
|
| |
An UPDATE emitted as a result of the
:paramref:`.relationship.post_update` feature will now integrate with
the versioning feature to both bump the version id of the row as well
as assert that the existing version number was matched.
Fixes: #3496
Change-Id: I865405dd6069f1c1e3b0d27a4980e9374e059f97
|
| |
|
|
|
|
|
|
|
|
|
| |
Adjusted the behavior of post_update such that if a column with
an "onupdate" default has received an explicit value for
INSERT, re-send the same data during a post-update UPDATE so
that the value remains in effect, rather than an onupdate
overwriting it.
Change-Id: I26bccb6f957dcad07a2bcbda2dd9e14c60b92b06
Fixes: #3471
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fixed bug involving the :paramref:`.relationship.post_update` feature
where a column "onupdate" value would not result in expiration or
refresh of the corresponding object attribute, if the UPDATE for the
row were a result of the "post update" feature. Additionally, the
:meth:`.SessionEvents.refresh_flush` event is now emitted for these
attributes when refreshed within the flush.
Fixes: #3472
Change-Id: I5ee2d715e773a306ab1e8143e4382c228991ac78
|
| |
|
|
|
|
|
|
|
| |
The versioning feature does not support NULL for the version counter.
An exception is now raised if the version id is programmatic and
was set to NULL for an UPDATE. Pull request courtesy Diana Clarke.
Fixes: #3673
Change-Id: I8b0da56234a7c7f5e7fde35536e09a6216a5e48a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed bug where programmatic version_id counter in conjunction with
joined table inheritance would fail if the version_id counter
were not actually incremented and no other values on the base table
were modified, as the UPDATE would have an empty SET clause. Since
programmatic version_id where version counter is not incremented
is a documented use case, this specific condition is now detected
and the UPDATE now sets the version_id value to itself, so that
concurrency checks still take place.
Change-Id: I80e385bffeed4851cc20131cbe983c173a46f655
Fixes: #3996
|
| |
|
|
|
|
|
|
|
|
| |
Fixed bug where a :func:`.column_property` that is also marked as
"deferred" would be marked as "expired" during a flush, causing it
to be loaded along with the unexpiry of regular attributes even
though this attribute was never accessed.
Change-Id: Iaa9e17b66ece30a8e729e4af746b31ff99b1ec9a
Fixes: #3984
|
| |
|
|
|
|
|
|
|
|
|
| |
The :meth:`.Query.update` method can now accommodate both
hybrid attributes as well as composite attributes as a source
of the key to be placed in the SET clause. For hybrids, an
additional decorator :meth:`.hybrid_property.update_expression`
is supplied for which the user supplies a tuple-returning function.
Change-Id: I15e97b02381d553f30b3301308155e19128d2cfb
Fixes: #3229
|
| |
|
|
|
|
|
| |
After bump minimum supported version to 2.7 (1da9d3752160430c91534a8868ceb8c5ad1451d4), we can use new syntax.
Change-Id: Ib064c75a00562e641d132f9c57e5e69744200e05
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/347
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed two closely related bugs involving the mapper eager_defaults
flag in conjunction with single-table inheritance; one where the
eager defaults logic would inadvertently try to access a column
that's part of the mapper's "exclude_properties" list (used by
Declarative with single table inheritance) during the eager defaults
fetch, and the other where the full load of the row in order to
fetch the defaults would fail to use the correct inheriting mapper.
Fixes: #3908
Change-Id: Ie745174c917d512e2c46d9e3cc14512cde53cc9a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed a major inefficiency in the "eager_defaults" feature whereby
an unnecessary SELECT would be emitted for column values where the
ORM had explicitly inserted NULL, corresponding to attributes that
were unset on the object but did not have any server default
specified, as well as expired attributes on update that nevertheless
had no server onupdate set up. As these columns are not part of the
RETURNING that eager_defaults tries to use, they should not be
post-SELECTed either.
Change-Id: I0d4f1e9d3d9717d68dcc0592f69456a1f1c36df8
Fixes: #3909
|
| |
|
|
| |
Change-Id: I4e8c2aa8fe817bb2af8707410fa0201f938781de
|
| |
|
|
|
|
|
|
|
| |
The version id needs to be part of _changed_dict()
so that the value is present to send to
_emit_update_statements()
Change-Id: Ia85f0ef7714296a75cdc6c88674805afbbe752c8
Fixes: #3781
|
| |
|
|
|
|
|
|
| |
Fixed bug in :meth:`.Session.bulk_update_mappings` where an alternate-named
primary key attribute would not track properly into the UPDATE statement.
Change-Id: I33e9140f45827772768fa548adcfeb4dbfc2208d
Fixes: #3849
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change to "evaluates none" datatypes in the ORM was
not fully described in the migration notes, missing the
key behavioral change that a column which is missing a default
entirely will not receive a value for a missing JSON column now.
The issue here touched upon a revisit of the assumptions
in [ticket:3514], but overall the old behavior "worked" mostly
because the ORM wants to explicitly render NULL into an INSERT
for column values that are missing, which itself is a legacy
behavior which should be considered for possible removal in
a future major release. Given that "missing ORM value + no
column default set up == dont put it in the INSERT" would be
the most intuitive behavior, the move in [ticket:3514] represents
a step in this direction.
Change-Id: I454d5bb0773bd73d9864925dcc47f1f0810e33ba
Fixes: #3830
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ORM attributes can now be assigned any object that is has a
``__clause_element__()`` attribute, which will result in inline
SQL the way any :class:`.ClauseElement` class does. This covers other
mapped attributes not otherwise transformed by further expression
constructs.
As part of this, it was considered that we could add
__clause_element__() to ClauseElement, however this causes endless loops
in a "while" pattern and this pattern has been identified in third
party libraries. Add a test to ensure we never make that change.
Change-Id: I9e15b3f1c4883fd3909acbf7dc81d034c6e3ce1d
Fixes: #3802
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Removes an unnecessary transfer of modified PK column
value to the params dictionary, so that if the modified PK column
is already present in value_params, this remains in effect. Also
propagate a new flag through to _emit_update_statements() that will
trip "return_defaults()" across the board if a PK col w/ SQL expression
change is present, and pull this PK value in _postfetch as well assuming
we're an UPDATE.
Change-Id: I9ae87f964df9ba8faea8e25e96b8327f968e5d1b
Fixes: #3801
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, ``Session.bulk_insert_mappings`` omits NULL values which
causes it to break up batches of inserts based on which batches
contain NULL and which do not.
By adding this flag, the same columns are rendered in the INSERT
for all rows allowing them to be batched. The downside is that
server-side defaults are omitted.
Doctext-author: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: Iec5969304d4bdbf57290b200331bde02254aa3a5
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/243
|
| |
|
|
|
|
|
|
|
| |
would still potentially cause persistence conflicts on the next
transaction, because the instance would not be checked that it
was expired. This fix will resolve a large class of cases that
erronously cause the "New instance with identity X conflicts with
persistent instance Y" error.
fixes #3677
|
| | |
|
| |
|
|
|
|
|
|
| |
available mapper options. This allows a DELETE to proceed
for a joined-table inheritance mapping against the base table only,
while allowing for ON DELETE CASCADE to handle deleting the row
from the subclass tables.
fixes #2349
|
| |
|
|
|
|
| |
the same cached starting statement each time. no issue has been observed
with the former but it could perhaps have issues w/ versioning
or eager_defaults
|
| |
|
|
|
|
|
|
| |
would not bump a version id counter when in use. The experience
here is still a little rough as the original version id is required
in the given dictionaries and there's not clean error reporting
on that yet.
fixes #3610
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
insert-default holding columns not otherwise included in the SET
clause (such as primary key cols) to get rendered into the RETURNING
even though this is an UPDATE.
- Major fixes to the :paramref:`.Mapper.eager_defaults` flag, this
flag would not be honored correctly in the case that multiple
UPDATE statements were to be emitted, either as part of a flush
or a bulk update operation. Additionally, RETURNING
would be emitted unnecessarily within update statements.
fixes #3609
|
| |
|
|
|
|
|
|
|
|
| |
statement. This feature is available by passing the
:paramref:`~.sqlalchemy.sql.expression.update.preserve_parameter_order`
flag either to the core :class:`.Update` construct or alternatively
adding it to the :paramref:`.Query.update.update_args` dictionary at
the ORM-level, also passing the parameters themselves as a list of 2-tuples.
Thanks to Gorka Eguileor for implementation and tests.
adapted from pullreq github:200
|
| |
|
|
| |
as versioning isn't needed, fixes test_unitofworkv2->test_update_multi_missing_broken_multi_rowcount
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
:meth:`.Session.bulk_save_objects` and related bulk methods have
been scaled back to the extent that this functionality is not
currently used, e.g. checks for column default values to be
fetched after an INSERT or UPDATE statement.
fixes #3526
|
| |
|
|
|
|
|
| |
column that had some kind of "fetch on update" value and was not
locally present in the given object would cause an AttributeError
within the operation.
fixes #3525
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Fixes to the ORM and to the postgresql JSON type regarding the
``None`` constant in conjunction with the Postgresql :class:`.JSON` type. When
the :paramref:`.JSON.none_as_null` flag is left at its default
value of ``False``, the ORM will now correctly insert the Json
"'null'" string into the column whenever the value on the ORM
object is set to the value ``None`` or when the value ``None``
is used with :meth:`.Session.bulk_insert_mappings`,
**including** if the column has a default or server default on it. This
makes use of a new type-level flag "evaluates_none" which is implemented
by the JSON type based on the none_as_null flag. fixes #3514
- Added a new constant :attr:`.postgresql.JSON.NULL`, indicating
that the JSON NULL value should be used for a value
regardless of other settings. part of fixes #3514
|
| |
|
|
|
|
|
|
|
| |
``__eq__()`` to return a non-boolean-capable object, such as
some geoalchemy types as well as numpy types, were being tested
for ``bool()`` during a unit of work update operation, where in
0.9 the return value of ``__eq__()`` was tested against "is True"
to guard against this.
fixes #3469
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
to suit #3451 exclude these columns from the "params"
dictionary in the first place, revises pr github:181
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Suppose you have a model class with a primary key.
Base = declarative_base()
class User(Base):
id = Column(BigInteger, primary_key=True)
name = Column(String)
Previously, running
`bulk_update_mappings(User, {'id': 1, 'name': 'hello'})`
would emit the following:
```UPDATE users SET id=1, name='hello' WHERE id=1```
This is contrary to the stated behaviour, where primary keys are omitted
from the SET clause. Furthermore, this behaviour is harmful, as it
can cause the db engine to lock over-aggresively (at least in Postgres).
With this change, the emitted SQL is:
```UPDATE users SET name='hello' WHERE id=1```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as a result of the bugfix for :ticket:`3167`,
where attribute and validation events are no longer
called within the flush process. The mutable
extension was relying upon this behavior in the case where a column
level Python-side default were responsible for generating the new value
on INSERT or UPDATE, or when a value were fetched from the RETURNING
clause for "eager defaults" mode. The new value would not be subject
to any event when populated and the mutable extension could not
establish proper coercion or history listening. A new event
:meth:`.InstanceEvents.refresh_flush` is added which the mutable
extension now makes use of for this use case.
fixes #3427
- Added new event :meth:`.InstanceEvents.refresh_flush`, invoked
when an INSERT or UPDATE level default value fetched via RETURNING
or Python-side default is invoked within the flush process. This
is to provide a hook that is no longer present as a result of
:ticket:`3167`, where attribute and validation events are no longer
called within the flush process.
- Added a new semi-public method to :class:`.MutableBase`
:meth:`.MutableBase._get_listen_keys`. Overriding this method
is needed in the case where a :class:`.MutableBase` subclass needs
events to propagate for attribute keys other than the key to which
the mutable type is associated with, when intercepting the
:meth:`.InstanceEvents.refresh` or
:meth:`.InstanceEvents.refresh_flush` events. The current example of
this is composites using :class:`.MutableComposite`.
|
| |
|
|
|
|
|
|
| |
where the check for query state on :meth:`.Query.update` or
:meth:`.Query.delete` compared the empty tuple to itself using ``is``,
which fails on Pypy to produce ``True`` in this case; this would
erronously emit a warning in 0.9 and raise an exception in 1.0.
fixes #3405
|
| |
|
|
|
|
|
|
|
| |
set to a SQL expression for an UPDATE, and the SQL expression when
compared to the previous value of the attribute would produce a SQL
comparison other than ``==`` or ``!=``, the exception "Boolean value
of this clause is not defined" would raise. The fix ensures that
the unit of work will not interpret the SQL expression in this way.
fixes #3402
|
| |
|
|
|
|
|
|
|
| |
to transient objects with attributes unset would leak NEVER_SET,
and negated_contains_or_equals would do so for any transient
object as the comparison used only the committed value.
Repaired the NEVER_SET cases, fixes #3371, and also made
negated_contains_or_equals() use state_attr_by_column() just
like a non-negated comparison, fixes #3374
|
| |\ |
|
| | |
| |
| |
| |
| | |
This is useful to be able to pass in mysql_limit=1 from using the
ORM.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FROM clauses when using the :meth:`.Query.update` or
:meth:`.Query.delete` methods; instead of silently ignoring these
fields if methods like :meth:`.Query.join` or
:meth:`.Query.select_from` has been called, an error is raised.
In 0.9.10 this only emits a warning.
fixes #3349
- don't needlessly call _compile_context() and build up a
whole statement that we never need. Construct QueryContext
as it's part of the event contract, but don't actually call upon
mapper attributes; use more direct systems of determining the
update or delete table.
- don't realy need _no_select_modifiers anymore
|
| | |
|
| |
|
|
|
|
| |
additional test
that is much more specific to #1326
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
:meth:`.Session.get_bind` method when calling upon
:meth:`.Query.count`, :meth:`.Query.update`, :meth:`.Query.delete`,
as well as queries against mapped columns,
:obj:`.column_property` objects, and SQL functions and expressions
derived from mapped columns. This allows sessions that rely upon
either customized :meth:`.Session.get_bind` schemes or "bound" metadata
to work in all relevant cases.
fixes #3227 fixes #3242 fixes #1326
|
| | |
|
| | |
|