| 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
|
| |
|
|
|
| |
:meth:`.ConnectionEvents.detach`,
:meth:`.ConnectionEvents.close_detached`.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
a savepoint being cancelled first covered in :ticket:`2696`,
the failure mode in which the :class:`.Session` is placed when a
SAVEPOINT vanishes before rollback has been improved to allow the
:class:`.Session` to still function outside of that savepoint.
It is assumed that the savepoint operation failed and was cancelled.
fixes #3680
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
via :paramref:`.create_engine.isolation_level` and
:paramref:`.Connection.execution_options.isolation_level`
parameters. fixes #3534
|
| |
|
|
|
|
| |
- make docs for isolation level more consistent between postgresql
and mysql
- move mysql autocommit tests
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
would still potentially cause persistence conflicts on the next
transaction, because the instance would not be checked that it
was expired. This fix will resolve a large class of cases that
erronously cause the "New instance with identity X conflicts with
persistent instance Y" error.
fixes #3677
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
test_update
- establish consistent names between existing unconsumed names tests and new ones
added per ref #3666
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| | |
that when a "polymorphic" entity is used which represents a straight
join of several tables, the statement will ensure that all the
tables within the join are part of what's correlating.
fixes #3662
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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)
|
| | |
| |
| |
| |
| |
| |
| | |
would be turned into a list of individual characters. This would
impact among other things using the :meth:`.Query.get` method
on a primary key that's a bytes object.
fixes #3660
|
| | |
| |
| |
| | |
the new behavior of the autoincrement flag as per ref #3216
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
to not be loaded, if the joined eager load were from a row where the
same entity were present multiple times, some calling for the attribute
to be eagerly loaded and others not. The logic here is revised to
take in the attribute even though a different loader path has
handled the parent entity already. fixes #3431
|
| | |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| | |
from https://bitbucket.org/zzzeek/sqlalchemy/issues/3297
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
primary key that has values for some but not all of the PK fields
would emit a SELECT statement leaking the internal NEVER_SET symbol
into the query, rather than detecting that this object does not have
a searchable primary key and no SELECT should be emitted.
fixes #3647
|
| | |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| | |
expression would not escape properly, e.g. ``some\:\:expr``, as is most
commonly required when rendering Postgresql-style CAST expressions.
fixes #3644
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
: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
|
| | | |
|
| | |
| |
| |
| | |
--backend-only
|
| | |
| |
| |
| | |
if not
|
| | |
| |
| |
| | |
same time
|
| | |
| |
| |
| |
| |
| | |
unfortunately the synonym doesn't work for SQL statements here
when the dblink is on a different user, testing this is not really
critical so just removed it.
|
| | |
| |
| |
| |
| | |
- move tests to CRUDTest
- changelog, fixes #3643
|
| | | |
|
| | |
| |
| |
| | |
- modernize those tests as well
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| | |
removed; this has emitted a warning for many years and projects
should be calling upon ``sqlalchemy.dialects.postgresql``.
Engine URLs of the form ``postgres://`` will still continue to function,
however.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the warning here to all safe_reraise() cases in Python 2.
- Revisiting :ticket:`2696`, first released in 1.0.10, which attempts to
work around Python 2's lack of exception context reporting by emitting
a warning for an exception that was interrupted by a second exception
when attempting to roll back the already-failed transaction; this
issue continues to occur for MySQL backends in conjunction with a
savepoint that gets unexpectedly lost, which then causes a
"no such savepoint" error when the rollback is attempted, obscuring
what the original condition was.
The approach has been generalized to the Core "safe
reraise" function which takes place across the ORM and Core in any
place that a transaction is being rolled back in response to an error
which occurred trying to commit, including the context managers
provided by :class:`.Session` and :class:`.Connection`, and taking
place for operations such as a failure on "RELEASE SAVEPOINT".
Previously, the fix was only in place for a specific path within
the ORM flush/commit process; it now takes place for all transational
context managers as well.
fixes #2696
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
in df3f125bd84fc7ec5d45592c5774daf3a39d9bc9, this flag is
explicitly checked within conftest.py and we need to continue to use
it, otherwise a tox build inside of .tox that isn't usedevelop
is ignored, including C extensions
- rework the whole system of running with coverage, so that
with coverage, we *are* using usedevelop, but also make sure
we rm the .so files for nocext, make sure we --cov-append, etc.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| | |
profiling problems here
- add extras_require to setup.py for the most common DBAPIs
- rework tox.ini to use extras, specify a test matrix built in
|
| | |
| |
| |
| |
| |
| | |
at the primary key of a row based on other tests invoking around it
(cherry picked from commit 7d70dfd412c05fd8349339da01b472bd3df02082)
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
w/ the number of drivers /DBURIs / python versions
|