| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
For example, this query:
SELECT s1.users.name FROM s1.users FOR UPDATE OF s1.users
should actually be:
SELECT s1.users.name FROM s1.users FOR UPDATE OF users
fixes #3573
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"auto increment" column has been changed, such that autoincrement
is no longer implicitly enabled for a :class:`.Table` that has a
composite primary key. In order to accommodate being able to enable
autoincrement for a composite PK member column while at the same time
maintaining SQLAlchemy's long standing behavior of enabling
implicit autoincrement for a single integer primary key, a third
state has been added to the :paramref:`.Column.autoincrement` parameter
``"auto"``, which is now the default. fixes #3216
- The MySQL dialect no longer generates an extra "KEY" directive when
generating CREATE TABLE DDL for a table using InnoDB with a
composite primary key with AUTO_INCREMENT on a column that isn't the
first column; to overcome InnoDB's limitation here, the PRIMARY KEY
constraint is now generated with the AUTO_INCREMENT column placed
first in the list of columns.
|
|
|
|
|
|
|
|
|
|
|
| |
expression element which is late-evaluated at compile time. Previously,
the function was only a conversion function which would handle different
expression inputs by returning either a :class:`.Label` of a column-oriented
expression or a copy of a given :class:`.BindParameter` object,
which in particular prevented the operation from being logically
maintained when an ORM-level expression transformation would convert
a column to a bound parameter (e.g. for lazy loading).
fixes #3531
|
|
|
|
|
|
|
|
|
|
|
| |
``<function> WITHIN GROUP (ORDER BY <criteria>)``, using the
method :class:`.FunctionElement.within_group`. A series of common
set-aggregate functions with return types derived from the set have
been added. This includes functions like :class:`.percentile_cont`,
:class:`.dense_rank` and others.
fixes #1370
- make sure we use func.name for all _literal_as_binds in functions.py
so we get consistent naming behavior for parameters.
|
|
|
|
|
|
| |
- any/all work for Array as well as subqueries, accepted by MySQL
- Postgresql ARRAY now subclasses Array
- fixes #3516
|
|
|
|
|
|
| |
or mapped instances into contexts where they are interpreted as
SQL bound parameters; a new exception is raised for this.
fixes #3321
|
| |
|
|
|
|
|
|
|
|
| |
un-adjusted internal symbol names for "anonymous" labels, which
are the "foo_1" types of labels we see generated for SQL functions
without labels and similar. This was a side effect of the
performance enhancements implemented as part of references #918.
fixes #3483
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
inside of :meth:`.Insert.from_select`. This behavior worked
accidentally up until 0.9.9, when it no longer worked due to
unrelated changes as part of :ticket:`3248`. Note that this
is the rendering of the WITH clause after the INSERT, before the
SELECT; the full functionality of CTEs rendered at the top
level of INSERT, UPDATE, DELETE is a new feature targeted for a
later release.
fixes #3418
|
|
|
|
|
|
|
|
|
|
| |
a label that overlapped another label that is not truncated; this
because the length threshhold for truncation was greater than
the portion of the label that remains after truncation. These
two values have now been made the same; label_length - 6.
The effect here is that shorter column labels will be "truncated"
where they would not have been truncated before.
fixes #3396
|
|
|
|
|
|
| |
with Firebird, so that the values are again rendered inline when
this is selected. Related to :ticket:`3034`.
fixes #3381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assign the proper result type of Boolean to the result mapping, and
instead would leak column types from within the query into the
result map. This issue exists in 0.9 and earlier as well, however
has less of an impact in those versions. In 1.0, due to #918
this becomes a regression in that we now rely upon the result mapping
to be very accurate, else we can assign result-type processors to
the wrong column. In all versions, this issue also has the effect
that a simple EXISTS will not apply the Boolean type handler, leading
to simple 1/0 values for backends without native boolean instead of
True/False. The fix includes that an EXISTS columns argument
will be anon-labeled like other column expressions; a similar fix is
implemented for pure-boolean expressions like ``not_(True())``.
fixes #3372
|
|
|
|
|
|
|
|
| |
a label that was anonymous, then labeled again with a name, would
fail to be locatable via a textual label. This situation occurs
naturally when a mapped :func:`.column_property` is given an
explicit label in a query.
fixes #3340
|
| |
|
|
|
|
|
| |
- replace force_result_map with a mini-API for nested result sets, add
coverage
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "wrapping" employed by the mssql and oracle dialects using the
"iswrapper" argument was not being used intelligently by the compiler,
and the result map was being written incorrectly, using
*more* columns in the result map than were actually returned by
the statement, due to "row number" columns that are inside the
subquery. The compiler now writes out result map on the
"top level" select in all cases
fully, and for the mssql/oracle wrapping case extracts out
the "proxied" columns in a second step, which only includes
those columns that are proxied outwards to the top level.
This change might have implications for 3rd party dialects that
might be imitating oracle's approach. They can safely continue
to use the "iswrapper" kw which is now ignored, but they may
need to also add the _select_wraps argument as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
such that they are matched to the received result set positionally,
rather than by name. Originally, this was seen as a way to handle
cases where we had columns returned with difficult-to-predict names,
though in modern use that issue has been overcome by anonymous
labeling. In this version, the approach basically reduces function
call count per-result by a few dozen calls, or more for larger
sets of result columns. The approach still degrades into a modern
version of the old approach if textual elements modify the result
map, or if any discrepancy in size exists between
the compiled set of columns versus what was received, so there's no
issue for partially or fully textual compilation scenarios where these
lists might not line up. fixes #918
- callcounts still need to be adjusted down for this so zoomark
tests won't pass at the moment
|
|
|
|
|
|
|
| |
when using the :paramref:`.Column.server_default` parameter, will
now be rendered using the "inline" compiler, so that they are rendered
as-is, rather than as bound parameters.
fixes #3087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
now be constructed such that the visit methods receive an indication
of the owning expression object, if any. Any visit method that
accepts keyword arguments (e.g. ``**kw``) will in most cases
receive a keyword argument ``type_expression``, referring to the
expression object that the type is contained within. For columns
in DDL, the dialect's compiler class may need to alter its
``get_column_specification()`` method to support this as well.
The ``UserDefinedType.get_col_spec()`` method will also receive
``type_expression`` if it provides ``**kw`` in its argument
signature.
fixes #3074
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sort_tables_and_constraints function.
- The DDL generation system of :meth:`.MetaData.create_all`
and :meth:`.Metadata.drop_all` has been enhanced to in most
cases automatically handle the case of mutually dependent
foreign key constraints; the need for the
:paramref:`.ForeignKeyConstraint.use_alter` flag is greatly
reduced. The system also works for constraints which aren't given
a name up front; only in the case of DROP is a name required for
at least one of the constraints involved in the cycle.
fixes #3282
|
|
|
|
|
|
|
| |
to the aliasing syntax, as well as a new CTE feature
:meth:`.CTE.suffix_with`, which is useful for adding in special
Oracle-specific directives to the CTE.
fixes #3220
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
return type is not strictly assumed to be boolean; it now
returns a :class:`.Boolean` subclass called :class:`.MatchType`.
The type will still produce boolean behavior when used in Python
expressions, however the dialect can override its behavior at
result time. In the case of MySQL, while the MATCH operator
is typically used in a boolean context within an expression,
if one actually queries for the value of a match expression, a
floating point value is returned; this value is not compatible
with SQLAlchemy's C-based boolean processor, so MySQL's result-set
behavior now follows that of the :class:`.Float` type.
A new operator object ``notmatch_op`` is also added to better allow
dialects to define the negation of a match operation.
fixes #3263
|
|
|
|
|
|
|
|
| |
collection has been made consistent; this attribute is now a
:class:`.ColumnCollection` like that of all other constraints and
is initialized at the point when the constraint is associated with
a :class:`.Table`.
fixes #3243
|
|
|
|
|
|
|
|
|
| |
INSERT, either through the values clause or as a "from select",
would pollute the column types used in the result set produced by
the RETURNING clause when columns from both statements shared the
same name, leading to potential errors or mis-adaptation when
retrieving the returning rows.
fixes #3248
|
|
|
|
| |
further fixes for #3034
|
|
|
|
|
|
|
| |
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
|