| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
for the SQL standard LATERAL keyword, currently only supported
by Postgresql. fixes #2857
|
|
|
|
| |
Pull request courtesy Stefan Urbanek. fixes #1957
|
|
|
|
|
|
|
| |
be properly typed as boolean in the result, and also would fail to be
anonymously aliased in a SELECT list as is the case with a
non-negated EXISTS construct.
fixes #3682
|
|
|
|
| |
#3666.
|
|
|
|
|
|
|
| |
we're trying to hit columns without names yet and such, to suit the bug
right now just make it specific to FunctionElement
(cherry picked from commit 785224a92f39bd5bdd05bbc66f4dd79736abded5)
|
|
|
|
|
|
|
|
|
| |
passed to :func:`.column_property`, so that if the same attribute
is referred to as a column expression twice the names are de-duped,
thus avoiding "ambiguous column" errors. Previously, the
``.label(None)`` would need to be applied in order for the name
to be de-anonymized.
fixes #3663
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
8ad968f33100baeb3b13c7e0b724b6b79ab4277f
for ref #3657. The Oracle dialect makes more use of the "select_wraps_for"
feature than SQL server because Oracle doesn't have "TOP" for a limit-only
select, so tests are showing more happening here. In the case where
the select() has some dupe columns, these are deduped from the .c collection
so a positional match between the wrapper and original can't use .inner_columns,
because these collections wont match. Using _columns_plus_names
instead which is the deduped collection that determines the SELECT display,
which definitely have to match up.
(cherry picked from commit aa9ce3f521f254da9879ede011e520ec35b8270e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handled within visit_select(); this attribute was added in the
1.0 series to accommodate the subquery wrapping behavior of
SQL Server and Oracle while also working with positional
column targeting and no longer relying upon "key fallback"
in order to target columns in such a statement. The IBM DB2
third-party dialect also has this use case, but its implementation
is using regular expressions to rewrite the textual SELECT only
and does not make use of a "wrapped" select at this time.
The logic no longer attempts to reconcile proxy set collections as
this was not deterministic, and instead assumes that the select()
and the wrapper select() match their columns postionally,
at least for the column positions they have in common,
so it is now very simple and safe. fixes #3657.
- as a side effect of #3657 it was also revealed that the
strategy of calling upon a ResultProxy._getter was not
correctly calling into NoSuchColumnError when an expected
column was not present, and instead returned None up to
loading.instances() to produce NoneType failures; added
a raiseerr argument to _getter() which is called when we
aren't expecting None, fixes #3658.
|
|
|
|
| |
exactly
|
|
|
|
|
| |
for example an exception object made within a test suite can
still repr (error seen in Keystone)
|
| |
|
|
|
|
|
|
|
|
|
| |
logging, exception, and ``repr()`` purposes now truncate very large
scalar values within each collection, including an
"N characters truncated"
notation, similar to how the display for large multiple-parameter sets
are themselves truncated.
fixes #2837
|
|
|
|
| |
here, fixes #3652
|
|
|
|
|
|
|
| |
INSERT, UPDATE, and DELETE statements to both specify their own
WITH clause, as well as for these statements themselves to be
CTE expressions when they include a RETURNING clause.
fixes #2551
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
:meth:`.Query.distinct` is combined with :meth:`.Query.order_by` such
that columns which are already present will not be added
a second time, even if they are labeled with a different name.
Regardless of this change, the extra columns added to the SQL have
never been returned in the final result, so this change only impacts
the string form of the statement as well as its behavior when used in
a Core execution context. Additionally, columns are no longer added
when the DISTINCT ON format is used, provided the query is not
wrapped inside a subquery due to joined eager loading.
fixes #3641
|
| |
|
|
|
|
|
| |
- move tests to CRUDTest
- changelog, fixes #3643
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #3095, #3292
- reorganize enum constructor to again work with the MySQL
ENUM type
- add a new create_constraint flag to Enum to complement that of
Boolean
- reinstate the CHECK constraint tests for enum, these already
fail /skip against the MySQL backend
- simplify lookup rules in Enum, have them apply to all varieties
of Enum equally
|
|
|
|
| |
within the Enum type.
|
|
|
|
|
|
|
|
|
| |
override with a column expression (e.g. by using ``'x' in col``)
would cause an endless loop in the case of an ARRAY type, as Python
defers this to ``__getitem__`` access which never raises for this
type. Overall, all use of ``__contains__`` now raises
NotImplementedError.
fixes #3642
|
| |
|
|
|
|
|
| |
what's given so we need to use a set() here. contains_column is not within
any performance paths
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
need this collection except in the extend/update uses where we
create it ad-hoc. simplifies pickling. Compatibility with 1.0
should be OK as ColumnColleciton uses __getstate__ in any case
and the __setstate__ contract hasn't changed.
- Fixed bug in :class:`.Table` metadata construct which appeared
around the 0.9 series where adding columns to a :class:`.Table`
that was unpickled would fail to correctly establish the
:class:`.Column` within the 'c' collection, leading to issues in
areas such as ORM configuration. This could impact use cases such
as ``extend_existing`` and others. fixes #3632
|
|
|
|
|
|
|
|
|
|
| |
as subqueries in order to work around SQLite's lack of support for this
syntax, is lifted when SQLite version 3.7.16 or greater is detected.
fixes #3634
- The workaround for SQLite's unexpected delivery of column names as
``tablename.columnname`` for some kinds of queries is now disabled
when SQLite version 3.10.0 or greater is detected.
fixes #3633
|
|
|
|
| |
create confusion for inherited classes such as BYTEA, fixes
|
|
|
|
|
|
|
|
|
|
| |
when the construct contains non-standard sql elements such as
returning, array index operations, or dialect-specific or custom
datatypes. a string is now returned in these cases rendering an
approximation of the construct (typically the postgresql-style
version of it) rather than raising an error. fixes #3631
- add within_group to top-level imports
- add eq_ignore_whitespace to sqlalchemy.testing imports
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
method, and its interaction with result-row processing, now allows
the columns passed to the method to be positionally matched with the
result columns in the statement, rather than matching on name alone.
The advantage to this includes that when linking a textual SQL statement
to an ORM or Core table model, no system of labeling or de-duping of
common column names needs to occur, which also means there's no need
to worry about how label names match to ORM columns and so-forth. In
addition, the :class:`.ResultProxy` has been further enhanced to
map column and string keys to a row with greater precision in some
cases. fixes #3501
- reorganize the initialization of ResultMetaData for readability
and complexity; use the name "cursor_description", define the
task of "merging" cursor_description with compiled column information
as its own function, and also define "name extraction" as a separate task.
- fully change the name we use in the "ambiguous column" error to be the
actual name that was ambiguous, modify the C ext also
|
|
|
|
|
| |
for SQL fragments; we've deprecated that in 1.0 and its a good idea
to document like this for 0.9 as well.
|
| |
|
|
|
|
| |
back by using an attrgetter for the default case
|
|
|
|
|
|
|
|
|
| |
This supports the use case of an application that uses the same set of
:class:`.Table` objects in many schemas, such as schema-per-user.
A new execution option
:paramref:`.Connection.execution_options.schema_translate_map` is
added. fixes #2685
- latest tox doesn't like the {posargs} in the profile rerunner
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
persistence of JSON values in MySQL as well as basic operator support
of "getitem" and "getpath", making use of the ``JSON_EXTRACT``
function in order to refer to individual paths in a JSON structure.
fixes #3547
- Added a new type to core :class:`.types.JSON`. This is the
base of the PostgreSQL :class:`.postgresql.JSON` type as well as that
of the new :class:`.mysql.JSON` type, so that a PG/MySQL-agnostic
JSON column may be used. The type features basic index and path
searching support.
fixes #3619
- reorganization of migration docs etc. to try to refer both to
the fixes to JSON that helps Postgresql while at the same time
indicating these are new features of the new base JSON type.
- a rework of the Array/Indexable system some more, moving things
that are specific to Array out of Indexable.
- new operators for JSON indexing added to core so that these can
be compiled by the PG and MySQL dialects individually
- rename sqltypes.Array to sqltypes.ARRAY - as there is no generic
Array implementation, this is an uppercase type for now, consistent
with the new sqltypes.JSON type that is also not a generic implementation.
There may need to be some convention change to handle the case of
datatypes that aren't generic, rely upon DB-native implementations,
but aren't necessarily all named the same thing.
|
|
|
|
|
|
|
|
| |
no longer called for an UPDATE or DELETE statement emitted via plain
text or via the :func:`.text` construct, affecting those drivers
that erase cursor.rowcount once the cursor is closed such as SQL
Server ODBC and Firebird drivers.
fixes #3622
|
|
|
|
|
|
|
|
| |
if a :class:`.Index` were associated with a :class:`.Column` that
is associated with a lower-case-t :class:`.TableClause`; the
association should be ignored for the purposes of associating
the index with a :class:`.Table`.
fixes #3616
|
| |
|
|
|
|
|
|
|
| |
remove "undoc members" that was putting some random server_default
atributes from ColumnClause
(cherry picked from commit 270301890ae87ec32a46bb17889d9776b7de1468)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
the :class:`.Select` construct would have its ``._raw_columns``
collection mutated in-place when compiling the :class:`.Insert`
construct, when the target :class:`.Table` has Python-side defaults.
The :class:`.Select` construct would compile standalone with the
erroneous column present subsequent to compilation of the
:class:`.Insert`, and the the :class:`.Insert` statement itself would
fail on a second compile attempt due to duplicate bound parameters.
fixes #3603
|
|
|
|
|
|
|
| |
such as a CHECK constraint would render an erroneous comma in the
definition; this scenario can occur such as with a Postgresql
INHERITS table that has no columns of its own.
fixes #3598
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
| |
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
|
|\ |
|