| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Output in the error message the table name and the column name.
|
| |
|
|
| |
Output in the error message the table name and the column name.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
that included the same single inh entity more than once
(normally this should raise an error) could, in some cases
depending on what was being joined "from", implicitly alias the
second case of the single inh entity, producing
a query that "worked". But as this implicit aliasing is not
intended in the case of single table inheritance, it didn't
really "work" fully and was very misleading, since it wouldn't
always appear.
fixes #3233
|
| |
|
|
|
|
|
| |
and :meth:`.Query.outerjoin` to a single-inheritance subclass
using ``of_type()`` would not render the "single table criteria" in
the ON clause if the ``from_joinpoint=True`` flag were set.
fixes #3232
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
the given object if the object had been subject to a delete
operation that was flushed, but not committed. This would also
affect related operations like :func:`.make_transient`.
fixes #3139
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ultimately will populate a foreign key column in conflict with
another, where the relationships are attempting to copy values
from different source columns. This occurs in the case where
composite foreign keys with overlapping columns are mapped to
relationships that each refer to a different referenced column.
A new documentation section illustrates the example as well as how
to overcome the issue by specifying "foreign" columns specifically
on a per-relationship basis.
fixes #3230
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
names in the given dictionary of values into mapped attribute names
against the mapped class being updated. Previously, string names
were taken in directly and passed to the core update statement without
any means to resolve against the mapped entity. Support for synonyms
and hybrid attributes as the subject attributes of
:meth:`.Query.update` are also supported.
fixes #3228
|
| | |
| |
| |
| | |
- pep8
|
| | |
| |
| |
| |
| |
| |
| | |
"binds" (e.g. engines to use), such engines can be associated with
mixin classes, concrete subclasses, as well as a wider variety
of table metadata such as joined inheritance tables.
fixes #3035
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
:meth:`.Query.outerjoin`, or the standalone :func:`.orm.join` /
:func:`.orm.outerjoin` functions to a single-inheritance subclass will
now include the "single table criteria" in the ON clause even
if the ON clause is otherwise hand-rolled; it is now added to the
criteria using AND, the same way as if joining to a single-table
target using relationship or similar.
fixes #3222
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
as that of :ticket:`3199`, when the ``named=True`` parameter
would be used. Some events would fail to register, and others
would not invoke the event arguments correctly, generally in the
case of when an event was "wrapped" for adaption in some other way.
The "named" mechanics have been rearranged to not interfere with
the argument signature expected by internal wrapper functions.
fixes #3197
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
method :meth:`.Query.with_statement_hint` to support statement-level
hints that are not specific to a table.
fixes #3206
|
| |/
|
|
| |
be contributing to pypy not cleaning up on this one
|
| |
|
|
|
|
|
| |
primaryjoin contained functions, while at the same time remote_side
was specified; the warning would suggest setting "remote side".
It now only emits if remote_side isn't present.
fixes #3194
|
| |
|
|
|
|
|
|
| |
thrown off during a collection replace event, if the
reorder_on_append flag were set to True. The fix ensures that the
ordering list only impacts the list that is explicitly associated
with the object.
fixes #3191
|
| |
|
|
|
|
|
|
| |
unify everything.
- create a new layer of separation between the "from order bys" and "column order bys",
so that an OVER doesn't ORDER BY a label in the same columns clause
- identify another issue with polymorphic for ref #3148, match on label
keys rather than the objects
|
| |
|
|
|
|
|
| |
and :meth:`.AttributeEvents.dispose_collection`, which track when
a collection is first associated with an instance and when it is
replaced. These handlers supersede the :meth:`.collection.linker`
annotation. The old hook remains supported through an event adapter.
|
| |
|
|
|
|
|
|
|
|
|
| |
we're now using; rework them fully so that their behavioral contract
is consistent regarding adapter.traverse() vs. adapter.columns[],
add a full suite of tests including advanced wrapping scenarios
previously only covered by test/orm/test_froms.py and
test/orm/inheritance/test_relationships.py
- identify several cases where label._order_by_label_clause would be
corrupted, e.g. due to adaption or annotation separately
- add full tests for #3148
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stringify a _label_reference() as is.
- add .key to _label_reference(), so that when _make_proxy()
is called, we don't call str() on it anyway.
- add a test to exercise Query's behavior of adding all the order_by
expressions to the columns list of the select, assert that things
work out when we have a _label_reference there, that it gets sucked
into the columns list and spit out on the other side, it's referred
to appropriately, etc. _label_reference() could theoretically
be resolved at the point we iterate _raw_columns() but
it's better to just let things work as they already do (except
nicer, since we get "tablename.colname" instead of just "somename"
in the columns list) so that we aren't adding a ton of overhead
to _columns_plus_names in the common case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructs are now importable from the "from sqlalchemy" namespace,
just like every other Core construct.
- The implicit conversion of strings to :func:`.text` constructs
when passed to most builder methods of :func:`.select` as
well as :class:`.Query` now emits a warning with just the
plain string sent. The textual conversion still proceeds normally,
however. The only method that accepts a string without a warning
are the "label reference" methods like order_by(), group_by();
these functions will now at compile time attempt to resolve a single
string argument to a column or label expression present in the
selectable; if none is located, the expression still renders, but
you get the warning again. The rationale here is that the implicit
conversion from string to text is more unexpected than not these days,
and it is better that the user send more direction to the Core / ORM
when passing a raw string as to what direction should be taken.
Core/ORM tutorials have been updated to go more in depth as to how text
is handled.
fixes #2992
|
| |
|
|
|
|
|
|
|
| |
N occurrences of a parameterized string. This allows parameterized
warnings that can refer to their arguments to be delivered a fixed
number of times until allowing Python warning filters to squelch them,
and prevents memory from growing unbounded within Python's
warning registries.
fixes #3178
|
| |
|
|
| |
are still OK, since these should be fine.
|
| |
|
|
|
|
| |
- 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
|
| | |
|
| |
|
|
| |
- inline the column-based expiration operations as well
|
| |
|
|
|
|
|
| |
if a load() or refresh() event changes history (which...why...but anyway)
the state of the object is the same; currently it seems that history
gets reset but on a refresh, the object still goes into session.dirty
- simplify what we store in partials
|
| |
|
|
|
|
|
|
| |
is used with mappings or options where eager loading, either
joined or subquery, would take place. These loading strategies are
not currently compatible with yield_per, so by raising this error,
the method is safer to use - combine with sending False to
:meth:`.Query.enable_eagerloads` to disable the eager loaders.
|
| |
|
|
|
|
|
|
|
|
| |
is applied, when using :meth:`.Query.from_self`, or its common
user :meth:`.Query.count`. The criteria to limit rows to those
with a certain type is now indicated on the inside subquery,
not the outside one, so that even if the "type" column is not
available in the columns clause, we can filter on it on the "inner"
query.
fixes #3177
|
| |
|
|
|
|
|
|
|
|
|
| |
any speed improvements :(. code is in a much better place to be run into
C, however
- The ``proc()`` callable passed to the ``create_row_processor()``
method of custom :class:`.Bundle` classes now accepts only a single
"row" argument.
- Deprecated event hooks removed: ``populate_instance``,
``create_instance``, ``translate_row``, ``append_result``
- the getter() idea is somewhat restored; see ref #3175
|
| |
|
|
|
|
|
|
|
|
| |
such that it has less chance of interfering with a joinload() in the
very rare circumstance that an object points to itself; in this
scenario, the object refers to itself while loading its attributes
which can cause a mixup between loaders. The use case of
"object points to itself" is not fully supported, but the fix also
removes some overhead so for now is part of testing.
fixes #3145
|
| | |
|
| |
|
|
|
|
|
| |
:paramref:`.relationship.innerjoin` is now to use "nested"
inner joins, that is, right-nested, as the default behavior when an
inner join joined eager load is chained to an outer join eager load.
fixes #3008
|
| | |
|
| | |
|
| |
|
|
|
|
| |
we only call upon the history API fully for primary key columns.
We also now skip the whole step of looking at PK columns and using
any history at all if no net changes are detected on the object.
|
| |
|
|
|
|
|
|
| |
``@validates`` would have events triggered within the flush process,
when those columns were the targets of a "fetch and populate"
operation, such as an autoincremented primary key, a Python side
default, or a server-side default "eagerly" fetched via RETURNING.
fixes #3167
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
into more performant executemany() call, similarly to how INSERT
statements can be batched; this will be invoked within flush
to the degree that subsequent UPDATE statements for the
same mapping and table involve the identical columns within the
VALUES clause, as well as that no VALUES-level SQL expressions
are embedded.
- some other inlinings within persistence.py
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
:class:`.SynonymProperty` and :class:`.ComparableProperty`.
- The ``info`` parameter has been added as a constructor argument
to all schema constructs including :class:`.MetaData`,
:class:`.Index`, :class:`.ForeignKey`, :class:`.ForeignKeyConstraint`,
:class:`.UniqueConstraint`, :class:`.PrimaryKeyConstraint`,
:class:`.CheckConstraint`.
fixes #2963
|
| | |
|
| |
|
|
| |
rules, better message formatting
|
