| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
defaults if otherwise unspecified; the limitation where non-
server column defaults aren't included in an INSERT FROM
SELECT is now lifted and these expressions are rendered as
constants into the SELECT statement.
|
|\ |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
CC goes from F to D
|
|/
|
|
|
|
| |
method :meth:`.Query.with_statement_hint` to support statement-level
hints that are not specific to a table.
fixes #3206
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "anonymize label" logic is now generalized to ClauseAdapter, and takes
place when the anonymize_labels flag is sent, taking effect for all
.columns lookups as well as within traverse() calls against the label
directly.
- traverse() will also memoize what it gets in columns, so that
calling upon traverse() / .columns against the same Label will
produce the same anonymized label. This is so that AliasedClass
produces the same anonymized label when it is accessed per-column
(e.g. SomeAlias.some_column) as well as when it is applied to a Query,
and within column loader strategies (e.g. query(SomeAlias)); the
former uses traverse() while the latter uses .columns
- AliasedClass now calls onto ColumnAdapter
- Query also makes sure to use that same ColumnAdapter from the AliasedClass
in all cases
- update the logic from 0.9 in #1068 to make use of the same
_label_resolve_dict we use for #2992, simplifying how that works
and adding support for new scenarios that were pretty broken
(see #3148, #3188)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on :class:`.Insert`. This helps to fix a bug where an
INSERT...FROM SELECT construct would inadvertently be compiled
as "implicit returning" on supporting backends, which would
cause breakage in the case of an INSERT that inserts zero rows
(as implicit returning expects a row), as well as arbitrary
return data in the case of an INSERT that inserts multiple
rows (e.g. only the first row of many).
A similar change is also applied to an INSERT..VALUES
with multiple parameter sets; implicit RETURNING will no longer emit
for this statement either. As both of these constructs deal
with varible numbers of rows, the
:attr:`.ResultProxy.inserted_primary_key` accessor does not
apply. Previously, there was a documentation note that one
may prefer ``inline=True`` with INSERT..FROM SELECT as some databases
don't support returning and therefore can't do "implicit" returning,
but there's no reason an INSERT...FROM SELECT needs implicit returning
in any case. Regular explicit :meth:`.Insert.returning` should
be used to return variable numbers of result rows if inserted
data is needed.
fixes #3169
|
|
|
|
|
|
| |
be always be correctly propagated when one CTE referred to another
aliased CTE in a statement.
Fixes #3154
|
|
|
|
| |
sqlalchemy/orm, sqlalchemy/event, sqlalchemy/testing
|
|
|
|
|
|
|
|
| |
as a scalar subquery such as within an IN would receive inappropriate
substitutions from the enclosing query, if the same table were present
inside the subquery as were in the enclosing query such as in a
joined inheritance scenario.
fixes #3130
|
|
|
|
|
| |
to again have the chance to veto rendering, as the naming convention
can make the decision that the name is "none" or not now.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint convention that includes ``constraint_name`` would
then force all :class:`.Boolean` and :class:`.Enum` types to
require names as well, as these implicitly create a
constraint, even if the ultimate target backend were one that does
not require generation of the constraint such as Postgresql.
The mechanics of naming conventions for these particular
constraints has been reorganized such that the naming
determination is done at DDL compile time, rather than at
constraint/table construction time.
fixes #3067
|
|
|
|
|
|
| |
parameters could be expressed in the wrong final order
when CTEs were nested in certain ways.
fixes #3090
|
|
|
|
|
|
| |
to check subsequent values entries beyond the first one given
for literal SQL expressions.
fixes #3069
|
|
|
|
| |
to get all flake8 passing
|
|
|
|
|
| |
the compiled cache is used. That allows us to cache the whole metadata
and save on creating it at result time, when compiled cache is used.
|
|
|
|
|
|
| |
Moved initialization into else block
Conflicts:
lib/sqlalchemy/sql/compiler.py
|
|\
| |
| |
| | |
https://bitbucket.org/dobesv/sqlalchemy/branch/issue_3034 into ticket_3034
|
| | |
|
| |
| |
| |
| | |
a BindParameter, instead of _offset and _limit in GenerativeSelect.
|
| |
| |
| |
| | |
on a query.
|
| |
| |
| |
| |
| |
| |
| | |
would produce an empty WHERE clause when an empty :func:`.and_()`
or :func:`.or_()` or other blank expression were applied. This is
now consistent with that of :func:`.select`.
fixes #3045
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"SELECT FIRST n ROWS" using a bound parameter (only firebird has both),
combined with column-level subqueries
which also feature "limit" as well as "positional" bound parameters
(e.g. qmark style) would erroneously assign the subquery-level positions
before that of the enclosing SELECT, thus returning parameters which
are out of order. Fixes #3038
|
|/
|
|
| |
Found using: https://github.com/intgr/topy
|
|
|
|
|
|
| |
feature from :ticket:`1068` would not apply quoting rules to the
label name as rendered in the ORDER BY.
fix #3020, re: #1068
|
|
|
|
|
|
|
| |
renders "BETWEEN SYMMETRIC". Also added a new negation operator
"notbetween_op", which now allows an expression like ``~col.between(x, y)``
to render as "col NOT BETWEEN x AND y", rather than a parentheiszed NOT
string. fixes #2990
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implemented right before the release of 0.9.3 affected the case where
a UNION contained nested joins in it. "Join rewriting" is a feature
with a wide range of possibilities and is the first intricate
"SQL rewriting" feature we've introduced in years, so we're sort of
going through a lot of iterations with it (not unlike eager loading
back in the 0.2/0.3 series, polymorphic loading in 0.4/0.5). We should
be there soon so thanks for bearing with us :).
fixes #2969 re: #2967
- solve the issue of join rewriting inspecting various types of
from objects without using isinstance(), by adding some new
underscored inspection flags to the FromClause hierarchy.
|
|
|
|
|
| |
on the columns clause of the SELECT statement if the targets were
aliased tables, as opposed to individual aliased columns.
|
|
|
|
|
| |
would fail to be rewritten properly, such as when the exists is
mapped to a column_property in an intricate nested-join scenario. #2967
|
|
|
|
|
|
|
| |
Have also considered linking column.label() to the "column" itself being
in the result map but this reveals some naming collision problems (that
also seem to be very poorly tested...). This should be as far as
we want to go right now with [ticket:2932].
|
|
|
|
|
|
| |
constructs would fail if the bind were constructed with a callable,
rather than a direct value. This prevented ORM expressions
from being rendered with the "literal_binds" compiler flag.
|
|
|
|
|
|
|
|
|
|
| |
such as "literal binds" into a CAST expression.
- Fixed bug whereby binary type would fail in some cases
if used with a "test" dialect, such as a DefaultDialect or other
dialect with no DBAPI.
- Fixed bug where "literal binds" wouldn't work with a bound parameter
that's a binary type. A similar, but different, issue is fixed
in 0.8.
|
|
|
|
|
|
|
|
|
|
|
| |
MySQL, to correctly render the SET clause among multiple columns
with the same name across tables. This also changes the name used for
the bound parameter in the SET clause to "<tablename>_<colname>" for
the non-primary table only; as this parameter is typically specified
using the :class:`.Column` object directly this should not have an
impact on applications. The fix takes effect for both
:meth:`.Table.update` as well as :meth:`.Query.update` in the ORM.
[ticket:2912]
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
yet the column is not the "auto increment" column, either because
it has a foreign key constraint or ``autoincrement=False`` set,
would attempt to fire the Sequence on INSERT for backends that don't
support sequences, when presented with an INSERT missing the primary
key value. This would take place on non-sequence backends like
SQLite, MySQL. [ticket:2896]
|
|
|
|
|
|
|
|
| |
of the given names would not be taken into account when generating
the INSERT statement, thus producing a mismatch versus the column
names in the given SELECT statement. Also noted that
:meth:`.Insert.from_select` implies that Python-side insert defaults
cannot be used, since the statement has no VALUES clause. [ticket:2895]
|
|
|
|
|
|
|
|
|
| |
backwards compatibility. A note about backslashing escapes is added.
Because the Text() construct now supports bind params better, the example
given in the code raises an exception now, so that should cover us.
The exception itself has been enhanced to include the key name of the
bound param. We're backporting this to 0.8 but 0.8 doesn't have the
text->bind behavior that raises.
|
| |
|
|
|
|
|
|
|
|
| |
more flexible ways to set up bound parameters and return types;
in particular, a :func:`.text` can now be turned into a full
FROM-object, embeddable in other statements as an alias or CTE
using the new method :meth:`.TextClause.columns`.
[ticket:2877]
|
|
|
|
|
|
| |
- move out tests, dialect specific out of compiler, compiler tests use new API,
legacy API tests in test_selecatble
- add support for adaptation of ForUpdateArg, alias support in compilers
|
| |
|