:class:`.CheckConstraint` associated with a :class:`.Boolean`
or :class:`.Enum` type object would be doubled in the target table.
The copy process now tracks the production of this constraint object
as local to a type object.
fixes#3260
collection has been made consistent; this attribute is now a
:class:`.ColumnCollection` like that of all other constraints and
is initialized at the point when the constraint is associated with
a :class:`.Table`.
fixes#3243
:class:`.SynonymProperty` and :class:`.ComparableProperty`.
- The ``info`` parameter has been added as a constructor argument
to all schema constructs including :class:`.MetaData`,
:class:`.Index`, :class:`.ForeignKey`, :class:`.ForeignKeyConstraint`,
:class:`.UniqueConstraint`, :class:`.PrimaryKeyConstraint`,
:class:`.CheckConstraint`.
fixes#2963
constraint convention that includes ``constraint_name`` would
then force all :class:`.Boolean` and :class:`.Enum` types to
require names as well, as these implicitly create a
constraint, even if the ultimate target backend were one that does
not require generation of the constraint such as Postgresql.
The mechanics of naming conventions for these particular
constraints has been reorganized such that the naming
determination is done at DDL compile time, rather than at
constraint/table construction time.
fixes#3067
Python version < 2.6.5, working around the
"no unicode keyword arg" bug as these args are passed along as
keyword args within some reflection processes.
fixes#3123
subclasses where direct association of the type with a
:class:`.MetaData` would lead to a hang when events
(like create events) were emitted on the :class:`.MetaData`.
fixes#3124
when that :class:`.Column` is referred to in an explicit
:class:`.PrimaryKeyConstraint` for that table. This behavior now
matches that of when the :class:`.Column` itself has the
:paramref:`.Column.primary_key` flag set to ``True``, which is
intended to be an exactly equivalent case.
fixes#3023
specify a :func:`.text` expression as the target; the index no longer
needs to have a table-bound column present if the index is to be
manually added to the table, either via inline declaration or via
:meth:`.Table.append_constraint`. fixes#3028
where the name of a check constraint making use of the
`"%(constraint_name)s"` token would get doubled up for the
constraint generated by a boolean or enum type, and overall
duplicate events would cause the `"%(constraint_name)s"` token
to keep compounding itself.
fixes#2991
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.
constructs has been enhanced in order to assist with existing
schemes that rely upon addition of ad-hoc keyword arguments to
constructs.
- To suit the use case of allowing custom arguments at construction time,
the :meth:`.DialectKWArgs.argument_for` method now allows this registration.
fixes#2962
the schema target of a :class:`.ForeignKey` will not be changed unless
that schema matches that of the parent table. That is, if
a table "schema_a.user" has a foreign key to "schema_b.order.id",
the "schema_b" target will be maintained whether or not the
"schema" argument is passed to :meth:`.Table.tometadata`. However
if a table "schema_a.user" refers to "schema_a.order.id", the presence
of "schema_a" will be updated on both the parent and referred tables.
This is a behavioral change hence isn't likely to be backported to
0.8; it is assumed that the previous behavior is pretty buggy
however and that it's unlikely anyone was relying upon it.
Additionally, a new parameter has been added
:paramref:`.Table.tometadata.referred_schema_fn`. This refers to a
callable function which will be used to determine the new referred
schema for any :class:`.ForeignKeyConstraint` encountered in the
tometadata operation. This callable can be used to revert to the
previous behavior or to customize how referred schemas are treated
on a per-constraint basis. [ticket:2913]
- rework the tests in test.sql.test_metadata, all the "tometadata" tests
now under new class ToMetaDataTest
applied to :class:`.Constraint` and :class:`.Index` objects. Based
on a recipe in the wiki, the new feature uses schema-events to set up
names as various schema objects are associated with each other. The
events then expose a configuration system through a new argument
:paramref:`.MetaData.naming_convention`. This system allows production
of both simple and custom naming schemes for constraints and indexes
on a per-:class:`.MetaData` basis. [ticket:2923]
commit 7e65e52c086652de3dd3303c723f98f09af54db8
Author: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Sat Feb 1 15:09:04 2014 -0500
- first pass at new naming approach
reflection now updates the PKC in place.
- support the use case of the empty PrimaryKeyConstraint in order to specify
constraint options; the columns marked as primary_key=True will now be gathered
into the columns collection, rather than being ignored. [ticket:2910]
- add validation such that column specification should only take place
in the PrimaryKeyConstraint directly, or by using primary_key=True flags;
if both are present, they have to match exactly, otherwise the condition is
assumed to be ambiguous, and a warning is emitted; the old behavior of
using the PKC columns only is maintained.
now represents exactly the kwargs that were passed, and not the defaults.
the defaults are still in dialect_options. This allows repr() schemes such as that
of alembic to not need to look through and compare for defaults.
column argument. If not a string, it checks that the object is
at least a :class:`.ColumnClause`, or an object that resolves to one,
and that the ``.table`` attribute, if present, refers to a
:class:`.TableClause` or subclass, and not something like an
:class:`.Alias`. Otherwise, a :class:`.ArgumentError` is raised.
[ticket:2883]
all :attr:`.SchemaItem.info` dictionaries from all :class:`.SchemaItem`
objects within the structure including columns, constraints,
foreign keys, etc. As these dictionaries
are copies, they are independent of the original dictionary.
Previously, only the ``.info`` dictionary of :class:`.Column` was transferred
within this operation, and it was only linked in place, not copied.
[ticket:2716]
if it was generated from a :class:`.Column` that didn't specify ``unique``
(where it defaults to ``None``). The flag will now always be ``True`` or
``False``. [ticket:2825]
events are called, so that attachment events can be used to dynamically
generate a name for the index based on the parent table and/or
columns. [ticket:2835]
instead of relying upon various ``quote=True`` flags being passed around,
these flags are converted into rich string objects with quoting information
included at the point at which they are passed to common schema constructs
like :class:`.Table`, :class:`.Column`, etc. This solves the issue
of various methods that don't correctly honor the "quote" flag such
as :meth:`.Engine.has_table` and related methods. The :class:`.quoted_name`
object is a string subclass that can also be used explicitly if needed;
the object will hold onto the quoting preferences passed and will
also bypass the "name normalization" performed by dialects that
standardize on uppercase symbols, such as Oracle, Firebird and DB2.
The upshot is that the "uppercase" backends can now work with force-quoted
names, such as lowercase-quoted names and new reserved words.
[ticket:2812]
target :class:`.Column` has been reworked to be as
immediate as possible, based on the moment that the
target :class:`.Column` is associated with the same
:class:`.MetaData` as this :class:`.ForeignKey`, rather
than waiting for the first time a join is constructed,
or similar. This along with other improvements allows
earlier detection of some foreign key configuration
issues. Also included here is a rework of the
type-propagation system, so that
it should be reliable now to set the type as ``None``
on any :class:`.Column` that refers to another via
:class:`.ForeignKey` - the type will be copied from the
target column as soon as that other column is associated,
and now works for composite foreign keys as well.
[ticket:1765]
foreign key paths to a table "B", to that table "B", would fail
to produce the "ambiguous join condition" error that would be
reported if you join table "A" directly to "B"; it would instead
produce a join condition with multiple criteria.
[ticket:2738]
now accommodate an empty list as an instruction to not create/drop
any items, rather than ignoring the collection. [ticket:2664].
This is a behavioral change and extra notes to the changelog
and migration document have been added.
- create a new test suite for exercising codepaths
in engine/ddl.py
:class:`.SchemaType` ``inherit_schema``. When set to ``True``,
the type will set its ``schema`` attribute of that of the
:class:`.Table` to which it is associated. This also occurs
during a :meth:`.Table.tometadata` operation; the :class:`.SchemaType`
is now copied in all cases when :meth:`.Table.tometadata` happens,
and if ``inherit_schema=True``, the type will take on the new
schema name passed to the method. The ``schema`` is important
when used with the Postgresql backend, as the type results in
a ``CREATE TYPE`` statement. [ticket:2657]
without passing the "for_update=True" flag would apply the default
object to the server_default, blowing away whatever was there.
The explicit for_update=True argument shouldn't be needed with this usage
(especially since the documentation shows an example without it being
used) so it is now arranged internally using a copy of the given default
object, if the flag isn't set to what corresponds to that argument.
Also in 0.7.10. [ticket:2631]
Mike Bayer