| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the warning here to all safe_reraise() cases in Python 2.
- Revisiting :ticket:`2696`, first released in 1.0.10, which attempts to
work around Python 2's lack of exception context reporting by emitting
a warning for an exception that was interrupted by a second exception
when attempting to roll back the already-failed transaction; this
issue continues to occur for MySQL backends in conjunction with a
savepoint that gets unexpectedly lost, which then causes a
"no such savepoint" error when the rollback is attempted, obscuring
what the original condition was.
The approach has been generalized to the Core "safe
reraise" function which takes place across the ORM and Core in any
place that a transaction is being rolled back in response to an error
which occurred trying to commit, including the context managers
provided by :class:`.Session` and :class:`.Connection`, and taking
place for operations such as a failure on "RELEASE SAVEPOINT".
Previously, the fix was only in place for a specific path within
the ORM flush/commit process; it now takes place for all transational
context managers as well.
fixes #2696
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
is random; therefore it may be called against the subclass mapper first, so
need to check .concrete on both sides, references #3630
|
| |
|
|
|
|
|
|
| |
a base class and a concrete-inherited subclass would raise an error
if those relationships were set up using "backref", while setting up the
identical configuration using relationship() instead with the conflicting
names would succeed, as is allowed in the case of a concrete mapping.
fixes #3630
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the :class:`.Engine` to which the :class:`.Session` is bound, when
generating the string form of the SQL, so that the actual SQL
that would be emitted to the database is shown, if possible. Previously,
only the engine associated with the :class:`.MetaData` to which the
mappings are associated would be used, if present. If
no bind can be located either on the :class:`.Session` or on
the :class:`.MetaData` to which the mappings are associated, then
the "default" dialect is used to render the SQL, as was the case
previously. fixes #3081
|
| |
|
|
|
| |
intelligible, given the fixes for ref #3623. unfortunately the system
is still quite weird even though it was rewritten to be... less weird
|
| |
|
|
|
|
|
| |
system failed to accommodate for multiple :func:`.undefer_group`
loader options in a single query. Multiple :func:`.undefer_group`
options will now be taken into account even against the same
entity. fixes #3623
|
| |\
| |
| |
| | |
updated docstrings for orm.scoping
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
for setting up baked lazy loaders would interfere with other
loader strategies that rely on lazy loading as a fallback, e.g.
joined and subquery eager loaders, leading to ``IndexError``
exceptions at mapper configuration time.
fixes #3612
|
| | |
| |
| |
| |
| |
| |
| | |
the check added for a polymorphic joinedload from a
poly_subclass->class->poly_baseclass connection would fail for the
scenario of class->poly_subclass->class.
fixes #3611
|
| | |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| | |
cause a subsequent call to the :meth:`.Query.with_parent` method to
fail. fixes #3606
- add mark-as-fail test for #3607
|
| | |
| |
| |
| |
| | |
back_populates while still maintaining great familiarity
w/ backref so as not to confuse people. fixes #3390
|
| |\ \ |
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| | |
Includes removal of adapt_like_to_iterable() as well
as _set_iterable(), uses __slots__ for collectionadapter,
does much less duck typing of collections.
|
| | |
| |
| |
| |
| | |
building on the example of query.join(). Ideally all the methods
in Query would have this kind of thing. fixes #3544
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
primary key before emitting an INSERT, and merges distinct objects with
duplicate primary keys together as they are encountered, which is
essentially semi-deterministic at best. This behavior
matches what happens already with persistent objects.
fixes #3601
|
| | |
| |
| |
| |
| |
| | |
fail to emit an UPDATE in the case where the attribute were set to
None and not previously loaded.
fixes #3599
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
The places inspect.getargspec was being used were causing problems for
newer Python versions.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
versions 0.8.0 and 0.8.1, due :ticket:`2714`. The case where
joined eager loading needs to join out over a subclass-bound
relationship when "with_polymorphic" were also used would fail
to join from the correct entity.
fixes #3593
|
| | | |
| | |
| | |
| | | |
that intercepts a query and adds entity-oriented criteria
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
limit/offset criteria that forces a subquery b. the relationship
uses "secondary" c. the primaryjoin of the relationship refers to
a column that is either not part of the primary key, or is a PK
col in a joined-inheritance subclass table that is under a different
attribute name than the parent table's primary key column d. the
query defers the columns that are present in the primaryjoin, typically
via not being included in load_only(); the necessary column(s) would
not be present in the subquery and produce invalid SQL.
fixes #3592
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
scope of a :meth:`.Session.flush` operation that's raising an
exception, as has been observed in some MySQL SAVEPOINT cases, prevents
the original database exception from being observed when it was
emitted during flush, but only on Py2K because Py2K does not support
exception chaining; on Py3K the originating exception is chained. As
a workaround, a warning is emitted in this specific case showing at
least the string message of the original database error before we
proceed to raise the rollback-originating exception.
fixes #2696
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
relationship flag; this flag *does* have an effect when the baked
lazy loader plugin has been invoked. clarify the intent of this
flag as an "opt out" but only has an effect when the baked system
is loaded anyway. fixes #3572
|
| |/ /
| |
| |
| |
| |
| |
| | |
added onto the end of a query in some inappropriate situations, such
as when querying from an exists() of a single-inheritance subclass.
fixes #3582
|
| | |
| |
| |
| | |
(cherry picked from commit 3ffe8569fbaa72c2d844604b600c4661097339eb)
|
| | |
| |
| |
| | |
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
|
| |\ \ |
|
| | | |
| | |
| | | |
Thanks to Mike Bayer for suggesting a simpler refactoring.
|
| |\ \ \ |
|
| | |/ / |
|
| |/ /
| |
| |
| |
| |
| |
| | |
may be construed as the Python "and" keyword
- add notes to ORM tutorial for beginners that Python "and" keyword
is not to be used
fixes #3545
|
| | |
| |
| |
| | |
- changelog / version note finishing
|
| | | |
|
| | |
| |
| |
| |
| | |
kinds of internal column loader options within internal logging.
fixes #3539
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
which indicates to the ORM that a positive set of None should be
persisted as the value NULL, instead of omitting the column from
the INSERT statement. This feature is used both as part of the
implementation for :ticket:`3514` as well as a standalone feature
available on any type. fixes #3250
- add new documentation section illustrating the "how to force null"
use case of #3250
- alter our change from #3514 so that the class-level flag is now
called "should_evaluate_none"; so that "evaluates_none" is now
a generative method.
|
| | |
| |
| |
| |
| |
| | |
to use mapper.cascade_iterator() for this purpose as it was not really
designed for that use case. Add docs to cascade_iterator() pointing
to the recipe. fixes #3498
|
| | |
| |
| |
| |
| |
| |
| |
| | |
: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
|