| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | |
| |
| |
| | |
- test_query isn't assertscompiledsql
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
that have problems with right-nested joins and UNION column keys;
references #3633 references #3634. backport from 1.1 to 0.9
announcing 1.1 as where these behaviors will be retired based
on version-specific checks
- fix test_resultset so that it passes when SQLite 3.10.0 is
present, references #3633
|
| | |
| |
| |
| |
| |
| |
| |
| | |
available mapper options. This allows a DELETE to proceed
for a joined-table inheritance mapping against the base table only,
while allowing for ON DELETE CASCADE to handle deleting the row
from the subclass tables.
fixes #2349
|
| | |
| |
| |
| |
| | |
when attempting to compile a query that includes "offset"; Sybase
has no straightforward "offset" feature. fixes #2278
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| | |
a base class and a concrete-inherited subclass would raise an error
if those relationships were set up using "backref", while setting up the
identical configuration using relationship() instead with the conflicting
names would succeed, as is allowed in the case of a concrete mapping.
fixes #3630
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
the :class:`.Engine` to which the :class:`.Session` is bound, when
generating the string form of the SQL, so that the actual SQL
that would be emitted to the database is shown, if possible. Previously,
only the engine associated with the :class:`.MetaData` to which the
mappings are associated would be used, if present. If
no bind can be located either on the :class:`.Session` or on
the :class:`.MetaData` to which the mappings are associated, then
the "default" dialect is used to render the SQL, as was the case
previously. fixes #3081
|
| | |
| |
| |
| |
| |
| |
| |
| | |
the exception to itself as the "cause"; while the Python 3 interpreter
is OK with this, it could cause endless loops in iPython.
fixes #3625
- add tests for reraise, raise_from_cause
- raise_from_cause is the same on py2k/3k, use just one function
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
intelligible, given the fixes for ref #3623. unfortunately the system
is still quite weird even though it was rewritten to be... less weird
|
| | |
| |
| |
| |
| |
| |
| | |
system failed to accommodate for multiple :func:`.undefer_group`
loader options in a single query. Multiple :func:`.undefer_group`
options will now be taken into account even against the same
entity. fixes #3623
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
be stated in the query string for a URL. Custom plugins can
be written which will be given the chance up front to alter and/or
consume the engine's URL and keyword arguments, and then at engine
create time will be given the engine itself to allow additional
modifications or event registration. Plugins are written as a
subclass of :class:`.CreateEnginePlugin`; see that class for
details.
fixes #3536
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| | |
such that we no longer assume the "ALGORITHM" keyword is present in
the reflected view source, as some users have reported this not being
present in some Amazon RDS environments.
fixes #3613
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
where the "default" argument was not included.
fixes #3605
|
| | |
| |
| |
| |
| |
| |
| |
| | |
for setting up baked lazy loaders would interfere with other
loader strategies that rely on lazy loading as a fallback, e.g.
joined and subquery eager loaders, leading to ``IndexError``
exceptions at mapper configuration time.
fixes #3612
|
| | |
| |
| |
| |
| |
| |
| | |
the check added for a polymorphic joinedload from a
poly_subclass->class->poly_baseclass connection would fail for the
scenario of class->poly_subclass->class.
fixes #3611
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
would not bump a version id counter when in use. The experience
here is still a little rough as the original version id is required
in the given dictionaries and there's not clean error reporting
on that yet.
fixes #3610
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|