membership removal
in issue #3844 we hypotheized that passive_deletes='all' was broken
because it sets to NULL a foreign key attribute when the child
object is removed or replaced. However, not doing the NULL
set means that nothing happens at all and the operation silently
fails.
Change-Id: I11834e7e324349e172dc797bac62731008b6b95a
Fixed bug where a :func:`.column_property` that is also marked as
"deferred" would be marked as "expired" during a flush, causing it
to be loaded along with the unexpiry of regular attributes even
though this attribute was never accessed.
Change-Id: Iaa9e17b66ece30a8e729e4af746b31ff99b1ec9a
Fixes: #3984
ORM attributes can now be assigned any object that is has a
``__clause_element__()`` attribute, which will result in inline
SQL the way any :class:`.ClauseElement` class does. This covers other
mapped attributes not otherwise transformed by further expression
constructs.
As part of this, it was considered that we could add
__clause_element__() to ClauseElement, however this causes endless loops
in a "while" pattern and this pattern has been identified in third
party libraries. Add a test to ensure we never make that change.
Change-Id: I9e15b3f1c4883fd3909acbf7dc81d034c6e3ce1d
Fixes: #3802
count() here is misleading in that it not only
counts from an arbitrary column in the table, it also
does not make accommodations for DISTINCT, JOIN, etc.
as the ORM-level function does. Core should not be
attempting to provide a function like this.
Change-Id: I9916fc51ef744389a92c54660ab08e9695b8afc2
Fixes: #3724
This is an old parameter no longer relevant to how SQLAlchemy
works, once the Query object was introduced. By deprecating it
we establish that we aren't supporting non-working use cases
and that we encourage applications to move off of the use of this
parameter.
Fixes: #3394
Change-Id: I25b9a38142a1537bbcb27d3e8b66a8b265140072
"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.
set to a SQL expression for an UPDATE, and the SQL expression when
compared to the previous value of the attribute would produce a SQL
comparison other than ``==`` or ``!=``, the exception "Boolean value
of this clause is not defined" would raise. The fix ensures that
the unit of work will not interpret the SQL expression in this way.
fixes#3402
into more performant executemany() call, similarly to how INSERT
statements can be batched; this will be invoked within flush
to the degree that subsequent UPDATE statements for the
same mapping and table involve the identical columns within the
VALUES clause, as well as that no VALUES-level SQL expressions
are embedded.
- some other inlinings within persistence.py
mapper is implicitly combining one of its column-based attributes
with that of the parent, where those columns normally don't necessarily
share the same value. This is an extension of an existing check that
was added via 🎫`1892`; however this new check emits only a
warning, instead of an exception, to allow for applications that may
be relying upon the existing behavior.
fixes#3042
to True, indicates that a series of DELETE statements should confirm
that the cursor rowcount matches the number of primary keys that should
have matched; this behavior had been taken off in most cases
(except when version_id is used) to support the unusual edge case of
self-referential ON DELETE CASCADE; to accomodate this, the message
is now just a warning, not an exception, and the flag can be used
to indicate a mapping that expects self-refererntial cascaded
deletes of this nature. See also 🎫`2403` for background on the
original change. re: #2403fix#3007
where one is to be deleted from ON DELETE CASCADE succeeds; the check here makes that fail.
We will need to add an option to enable/disable this check per mapping, will likely
do this in next version
is currently being supported in addition to nose, and will likely
be preferred to nose going forward. The nose plugin system used
by SQLAlchemy has been split out so that it works under pytest as
well. There are no plans to drop support for nose at the moment
and we hope that the test suite itself can continue to remain as
agnostic of testing platform as possible. See the file
README.unittests.rst for updated information on running tests
with pytest.
The test plugin system has also been enhanced to support running
tests against mutiple database URLs at once, by specifying the ``--db``
and/or ``--dburi`` flags multiple times. This does not run the entire test
suite for each database, but instead allows test cases that are specific
to certain backends make use of that backend as the test is run.
When using pytest as the test runner, the system will also run
specific test suites multiple times, once for each database, particularly
those tests within the "dialect suite". The plan is that the enhanced
system will also be used by Alembic, and allow Alembic to run
migration operation tests against multiple backends in one run, including
third-party backends not included within Alembic itself.
Third party dialects and extensions are also encouraged to standardize
on SQLAlchemy's test suite as a basis; see the file README.dialects.rst
for background on building out from SQLAlchemy's test platform.
to rely upon server generated version identifiers, using triggers
or other database-provided versioning features, by passing the value
``False``. The ORM will use RETURNING when available to immediately
load the new version identifier, else it will emit a second SELECT.
[ticket:2793]
- The ``eager_defaults`` flag of :class:`.Mapper` will now allow the
newly generated default values to be fetched using an inline
RETURNING clause, rather than a second SELECT statement, for backends
that support RETURNING.
- Added a new variant to :meth:`.ValuesBase.returning` called
:meth:`.ValuesBase.return_defaults`; this allows arbitrary columns
to be added to the RETURNING clause of the statement without interfering
with the compilers usual "implicit returning" feature, which is used to
efficiently fetch newly generated primary key values. For supporting
backends, a dictionary of all fetched values is present at
:attr:`.ResultProxy.returned_defaults`.
- add a glossary entry for RETURNING
- add documentation for version id generation, [ticket:867]
become an externally usable package but still remains within the main sqlalchemy parent package.
in this system, we use kind of an ugly hack to get the noseplugin imported outside of the
"sqlalchemy" package, while still making it available within sqlalchemy for usage by
third party libraries.
- break out key mechanics of loading objects
into new "orm.loading" module, removing implementation
details from both mapper.py and query.py. is analogous
to persistence.py
- some other cleanup and old cruft removal
for the benefit of the test.lib.schema package.
- use test.lib.schema.Table for the table within test.lib.fixtures.DeclarativeMappedTest
- [bug] Removed the check for number of
rows affected when doing a multi-delete
against mapped objects. If an ON DELETE
CASCADE exists between two rows, we can't
get an accurate rowcount from the DBAPI;
this particular count is not supported
on most DBAPIs in any case, MySQLdb
is the notable case where it is.
[ticket:2403]
so that we can get an accurate picture what's really running/not, what's installed on jenkins, etc.
Tested in cpython 2.7 so far, we'll see what jenkins says about other platforms
marks those properties that would otherwise be considered
to be "readonly", i.e. derived from SQL expressions,
to retain their value after a flush has occurred, including
if the parent object itself was involved in an update.
when the "identity" key isn't detected on
flush, to include the common cause that
the Column isn't set up to detect
auto-increment correctly; [ticket:2170].
Also in 0.6.8.
condition of being asked to UPDATE or DELETE
on a primary key value that contains NULL
in it. [ticket:2127]
- Some refinements to attribute history. More
changes are pending possibly in 0.8, but
for now history has been modified such that
scalar history doesn't have a "side effect"
of populating None for a non-present value.
This allows a slightly better ability to
distinguish between a None set and no actual
change, affects [ticket:2127] as well.
- rewriting the history tests in test_attributes to be
individual per operation/assertion. its a huge job
so this is partial for the moment.
access to the cls/self.tables/classes registries
- express orm/_base.py ORMTest in terms of engine/_base.py TablesTest,
factor out common steps into TablesTest, remove AltEngineTest as a
separate class. will further consolidate these base classes
- streamline interfaces, get Mutable/MutableComposite to be as minimal
in usage as possible
- docs for mutable, warnings regrarding mapper events being global
- move MutableType/mutable=True outwards, move orm tests to its
own module, note in all documentation
- still need more events/tests for correct pickling support of
composites, mutables. in the case of composites its needed
even without mutation. see [ticket:2009]
outside of "sqlalchemy" and under "test/".
Rationale:
- coverage plugin works without issue, without need for an awkward
additional package install
- command line for "nosetests" isn't polluted with SQLAlchemy options
[ticket:1949]
Mike Bayer