| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
here and require a flag on update() to use parameter ordering
rather than table ordering. more docs/changelog notes are needed
|
| |\ |
|
| | |
| |
| |
| |
| | |
Change _process_colparams method to remove duplicate isinstance calls
and try to speed up processing of the parameters.
|
| | |
| |
| |
| |
| | |
Remove added dict comprehensions that make this patch set non python 2.6
compatible.
|
| | |
| |
| |
| |
| |
| | |
Instead of checking multiple times if parameters are a dictionary in the
form of a tuple or list of value pairs, we check it only once and then
store it in the statement so it can be used on compilation time.
|
| | |
| |
| |
| |
| |
| |
| | |
Postpone as much as possible the change of update parameters to
OrderedDict from list or tuple of pairs.
This way we won't have problems with query's update method.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To avoid penalties for updates that do not require ordering, we will
only use OrderedDict for updates that receive a tuple or list of pairs,
and all kinds of dictionaries (dict, sqlalchemy's OrderedDict, or
collections.OrderedDict) will be treateated as unordered updates, just
like we were doing before.
This way this new feature will not change how updates behave for any
existing code and will only affect those that use the new ordered
feature.
This patch reverts update tests to how they were before as well as adds
a couple of tests to confirm that OrderedDicts are really treated like
normal dicts.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In some DBs the UPDATE operation is order dependent, so the operation
behaves differently depending on the order of the values.
As an example, imagine a volumes table with columns 'status' and
'previous_status' and we want to update a volume that has 'available' in
the status column.
If the SQL query is performed as:
UPDATE volumes SET previous_status=status, status='new' WHERE id=1;
This will result in a volume with 'new' status and 'available'
previous_status both on SQLite and MariaDB, but if we reverse the
columns:
UPDATE volumes SET status='new', previous_status=status WHERE id=1;
We will get the same result in SQLite but will result in a volume with
status and previous_status set to 'new' in MariaDB, which is not what we
want.
So order must be taken into consideration in some cases and it should be
allowed to ve specified via the Query update method or the values method
of an update.
This patch fixes this issue by preserving the order of parameters in
updates and allowing to receive not only dictionaries in update and
values but also ordered dictionaries and list/tuples of value pairs
(like dict and OrderedDict do).
fixes #3541
|
| | |
| |
| |
| |
| |
| |
| |
| | |
versions 0.8.0 and 0.8.1, due :ticket:`2714`. The case where
joined eager loading needs to join out over a subclass-bound
relationship when "with_polymorphic" were also used would fail
to join from the correct entity.
fixes #3593
|
| | | |
|
| | |
| |
| |
| | |
that intercepts a query and adds entity-oriented criteria
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
limit/offset criteria that forces a subquery b. the relationship
uses "secondary" c. the primaryjoin of the relationship refers to
a column that is either not part of the primary key, or is a PK
col in a joined-inheritance subclass table that is under a different
attribute name than the parent table's primary key column d. the
query defers the columns that are present in the primaryjoin, typically
via not being included in load_only(); the necessary column(s) would
not be present in the subquery and produce invalid SQL.
fixes #3592
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
scope of a :meth:`.Session.flush` operation that's raising an
exception, as has been observed in some MySQL SAVEPOINT cases, prevents
the original database exception from being observed when it was
emitted during flush, but only on Py2K because Py2K does not support
exception chaining; on Py3K the originating exception is chained. As
a workaround, a warning is emitted in this specific case showing at
least the string message of the original database error before we
proceed to raise the rollback-originating exception.
fixes #2696
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
to return ``datetime.timedelta`` in the same way as that of
:obj:`.types.Interval.python_type`, rather than raising
``NotImplementedError``.
fixes #3571
(cherry picked from commit 29d6f6e19b014bb5ce79032bd8803e32b4da0e5e)
|
| | |
| |
| |
| |
| |
| |
| | |
relationship flag; this flag *does* have an effect when the baked
lazy loader plugin has been invoked. clarify the intent of this
flag as an "opt out" but only has an effect when the baked system
is loaded anyway. fixes #3572
|
| | |
| |
| |
| |
| |
| | |
to the Postgresql version of the :meth:`.Inspector.get_view_definition`
method.
fixes #3587
|
| | |
| |
| |
| |
| |
| | |
which also accept zero precision
- extend test case here to include a backend-agnostic suite
- changelog for MSSQL date fix
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | | |
The simple check on the precision results in DATETIME2(0) generating a
DATETIME2 column, with default precision, which is 7.
|
| |/ / |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
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
|
| |\ \
| | |
| | |
| | | |
'jeffwidman/update-links-in-sqlalchemy-docs-that-poi-1446667164356' of https://bitbucket.org/jeffwidman/sqlalchemy
|
| | | | |
|
| | | |
| | |
| | |
| | | |
rather than hardcoded version
|
| |/ / |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
function; the caller still passes in the "wrapper"
- move tests for wrap_callable() to be generic util tests
- changelog for pullreq github:204
|
| | | |
| | |
| | |
| | | |
__name__, __doc__, and __module__
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
engine_connect event, allowing easy detection of disconnects
and full invalidation of the pool
|
| | | |
| | |
| | |
| | | |
(cherry picked from commit 3ffe8569fbaa72c2d844604b600c4661097339eb)
|
| | | |
| | |
| | |
| | | |
as versioning isn't needed, fixes test_unitofworkv2->test_update_multi_missing_broken_multi_rowcount
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
for UPDATE statements in the ORM (e.g. :ref:`feature_updatemany`)
would break on Postgresql and other RETURNING backends
when using server-side version generation
schemes, as the server side value is retrieved via RETURNING which
is not supported with executemany.
fixes #3556
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
:class:`.AssociationProxy` constructor, to suit the
:attr:`.AssociationProxy.info` accessor that was added in
:ticket:`2971`. This is possible because :class:`.AssociationProxy`
is constructed explicitly, unlike a hybrid which is constructed
implicitly via the decorator syntax.
fixes #3551
|
| |\ \ \ |
|
| | |/ /
| | |
| | | |
Thanks to Mike Bayer for suggesting a simpler refactoring.
|
| |\ \ \ |
|
| | |/ / |
|
| | | |
| | |
| | |
| | | |
"auto" now so True can indicate the dialect would support this
|
| |\ \ \ |
|
| | | | |
| | | |
| | | | |
Docstring typo keysowrds => keywords
|
| |/ / /
| | |
| | |
| | | |
"auto", doesn't matter if there's a default here
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
"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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
symbols with names quoted to force all-lower-case would not be
identified properly in reflection queries. The :class:`.quoted_name`
construct is now applied to incoming symbol names that detect as
forced into all-lower-case within the "name normalize" process.
fixes #3548
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
may be construed as the Python "and" keyword
- add notes to ORM tutorial for beginners that Python "and" keyword
is not to be used
fixes #3545
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
implicit schema
- repair the CREATE INDEX ddl for schemas
- update provisioning to include support for setting up ATTACH DATABASE up front
for the test_schema; enable "schemas" testing for SQLite
- changelog / migration notes for new SQLite schema support
- include the "schema" as the "remote_schema" when we reflect SQLite FKs
|
| |\ \ \
| |/ /
|/| | |
|