| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
to protect against unknown conditions when splicing inner joins
together within joined eager loads with ``innerjoin=True``; if
some of the joins use a "secondary" table, the assertion needs to
unwrap further joins in order to pass.
fixes #3412
|
| |
|
|
|
|
|
|
|
| |
as failing with the new 'entity' key value added to
:attr:`.Query.column_descriptions`, the logic to discover the "from"
clause is again reworked to accommodate columns from aliased classes,
as well as to report the correct value for the "aliased" flag in these
cases.
fixes #3409
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
of ``entity`` to the :attr:`.Query.column_descriptions` accessor
would fail if the target entity was produced from a core selectable
such as a :class:`.Table` or :class:`.CTE` object.
fixes #3403 references #3320
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
exprssed -> expressed
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
event where its invocation was moved to be after the class manager's
instrumentation of the class, which is the opposite of what the
documentation for the event explicitly states. The rationale for the
switch was due to Declarative taking the step of setting up
the full "instrumentation manager" for a class before it was mapped
for the purpose of the new ``@declared_attr`` features
described in :ref:`feature_3150`, but the change was also made
against the classical use of :func:`.mapper` for consistency.
However, SQLSoup relies upon the instrumentation event happening
before any instrumentation under classical mapping.
The behavior is reverted in the case of classical and declarative
mapping, the latter implemented by using a simple memoization
without using class manager.
fixes #3388
|
| |
|
|
|
|
|
| |
changes made to the :class:`.Query` object's collection of entities
to load within the event would render in the SQL, but would not
be reflected during the loading process.
fixes #3387
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
NEVER_SET symbol could easily leak into a lazyload query, subsequent
to the flush of a pending object. This would occur typically
for a many-to-one relationship that does not use a simple
"get" strategy. The good news is that the fix improves efficiency
vs. 0.9, because we can now skip the SELECT statement entirely
when we detect NEVER_SET symbols present in the parameters; prior to
:ticket:`3061`, we couldn't discern if the None here were set or not.
fixes #3368
|
| |
|
|
|
|
|
|
|
|
|
| |
same target more than once; it implicitly dedupes only in the case of
a relationship join, and due to :ticket:`3233`, in 1.0 a join
to the same table twice behaves differently than 0.9 in that it no
longer erroneously aliases. To help document this change,
the verbiage regarding :ticket:`3233` in the migration notes has
been generalized, and a warning has been added when :meth:`.Query.join`
is called against the same target relationship more than once.
fixes #3367
|
| |
|
|
|
|
|
|
|
| |
determining remote side with semi-self-referential (e.g. two joined
inh subclasses referring to each other), non-simple join conditions
such that the parententity is taken into account and can reduce the
need for using the ``remote()`` annotation; this can restore some
cases that might have worked without the annotation prior to 0.9.4
via :ticket:`2948`. fixes #3364
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| | |
This is useful to be able to pass in mysql_limit=1 from using the
ORM.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
:meth:`.Session.begin_nested` operations would fail to propagate
the "dirty" flag for an object that had been updated within
the inner savepoint, such that if the enclosing savepoint were
rolled back, the object would not be part of the state that was
expired and therefore reverted to its database state.
fixes #3352
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| | |
commit phase of the session, which without it could cause
a "dictionary changed size during iter" error if garbage collection
interacted within the process. Change was introduced by
|
| | |
| |
| |
| |
| | |
between fully and match on those, rather than trying to
compare selectables; fixes #3347
|
| |/
|
|
|
|
|
|
|
|
| |
exists in 0.9 as well but is more of a regression in 1.0 due to
:ticket:`3008` which turns on "nested" by default, such that
a joined eager load that travels across sibling paths from a common
ancestor using innerjoin=True will correctly splice each "innerjoin"
sibling into the appropriate part of the join, when a series of
inner/outer joins are mixed together.
fixes #3347
|
| | |
|
| |
|
|
| |
to be using getattr
|
| |
|
|
|
|
|
|
| |
simple but unusual system allows for a dramatic savings in Python
overhead for the construction and processing of orm :class:`.Query`
objects, from query construction up through rendering of a string
SQL statement.
fixes #3054
|
| |
|
|
|
|
|
|
|
| |
:attr:`.Query.column_descriptions`. This refers to the primary ORM
mapped class or aliased class that is referred to by the expression.
Compared to the existing entry for ``"type"``, it will always be
a mapped entity, even if extracted from a column expression, or
None if the given expression is a pure core expression.
references #3320
|
| |
|
|
|
|
|
|
|
|
|
| |
:meth:`.QueryEvents.before_compile` event allows the creation
of functions which may place additional modifications to
:class:`.Query` objects before the construction of the SELECT
statement. It is hoped that this event be made much more
useful via the advent of a new inspection system that will
allow for detailed modifications to be made against
:class:`.Query` objects in an automated fashion.
fixes #3317
|
| |
|
|
|
|
|
|
|
| |
is used with a one-to-many query that also features LIMIT,
OFFSET, or DISTINCT has been disabled in the case of a one-to-one
relationship, that is a one-to-many with
:paramref:`.relationship.uselist` set to False. This will produce
more efficient queries in these cases.
fixes #3249
|
| |
|
|
|
|
|
| |
attached to session X" would fail to prevent the object from
also being attached to the new session, in the case that execution
continued after the error raise occurred.
fixes #3301
|
| | |
|
| | |
|
| |
|
|
| |
for the slots-based __getattr__ thing getting hit
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a much more modest outcome than what we started with. The
work of create_row_processor() for ColumnProperty objects
is essentially done at query setup time combined with some
lookups in _instance_processor().
- to allow this change for deferred columns, deferred columns
no longer search for themselves in the result. If they've been
set up as deferred without any explicit directive to undefer them,
then this is what was asked for. if we don't do this,
then we're stuck with this performance penalty for all deferred
columns which in the vast majority of typical use cases (e.g. loading
large, legacy tables or tables with many/large very seldom
used values) won't be present in the result and won't be accessed at all.
|
| |
|
|
|
|
|
|
|
|
| |
many-to-one ``!= None`` would fail if the source were an aliased
class, or if the query needed to apply special aliasing to the
expression due to aliased joins or polymorphic querying; also fixed
bug in the case where comparing a many-to-one to an object state
would fail if the query needed to apply special aliasing
due to aliased joins or polymorphic querying.
fixes #3310
|
| | |
|
| |
|
|
|
|
|
|
| |
an ``after_rollback()`` handler for a :class:`.Session` incorrectly
adds state to that :class:`.Session` within the handler, and the task
to warn and remove this state (established by :ticket:`2389`) attempts
to proceed.
fixes #3309
|
| |
|
|
|
|
|
|
| |
in callcounts specific to the "expiration" of objects, as in
the "auto expire" feature of :meth:`.Session.commit` and
for :meth:`.Session.expire_all`, as well as in the "cleanup" step
which occurs when object states are garbage collected.
fixes #3307
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Conflicts:
lib/sqlalchemy/orm/query.py
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
with :meth:`.Connection.execution_options` when a :class:`.Transaction`
is in play; DBAPIs and/or SQLAlchemy dialects such as psycopg2,
MySQLdb may implicitly rollback or commit the transaction, or
not change the setting til next transaction, so this is never safe.
- Added new parameter :paramref:`.Session.connection.execution_options`
which may be used to set up execution options on a :class:`.Connection`
when it is first checked out, before the transaction has begun.
This is used to set up options such as isolation level on the
connection before the transaction starts.
- added new documentation section
detailing best practices for setting transaction isolation with
sessions.
fixes #3296
|
| | |
| |
| |
| |
| |
| |
| |
| | |
primaryjoin that referred to the same "local" column multiple
times in the "column that points to itself" style of self-referential
join would not be substituted in all cases. The logic to determine
substitutions here has been reworked to be more open-ended.
fixes #3300
|
| | |
| |
| |
| | |
this would cause LazyLoader to be initialized twice per property.
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | | |
|
| | | | |
|
