| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
so all autogenerates were spitting out batch mode...this has been
fixed so that batch mode again is only when selected in env.py.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
as stated
|
|
|
|
| |
from the preceding sections.
|
|
|
|
|
|
|
|
|
| |
argument to :meth:`.Operations.batch_alter_table`, as this is necessary
in order to drop foreign key constraints; these are often unnamed
on the target database, and in the case that they are named, SQLAlchemy
is as of the 0.9 series not including these names yet.
- rework the docs on batch + constraints, which remains subject
to a lot of caveats and problems, some to be resolved in SQLAlchemy 1.0
|
|
|
|
|
| |
- changelog and other doc updates, fixes #178
- fix drop_constraint() unit tests and add two more for FKs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- getting at attributes of FKs varies a bit on SQLA versions,
so implement an _fk_spec() called for all FK inspection
- to enable include_object() filters and allow the FK constraint
code to flow like that of indexes/uniques, change the approach
so that we deal with an _fk_constraint_sig() object again which
contains the real ForeignKeyConstraint() within; we need this
anyway for include_object, but also allows us to use the standard
"drop_constraint" call for rendering.
- enhance tests in test_autogen_fks to support real FK databases like
Postgresql, MySQL, add in InnoDB flags and ensure that FKs refer
to real primary key constraints for PG support
- implement and test include_object() support for FKs
- inspectors all have get_foreign_keys(), no need to check
- repair the drop_constraint call to quote the "type" and table
name correctly, run all constraint drops through drop_constraint()
for rendering
- fix up schema identifiers for foreign key autogens
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
into pr32
- complete merge, get all tests passing
- use 'foreignkey' literal
Conflicts:
alembic/autogenerate/compare.py
tests/test_autogenerate.py
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
fixes issue #178
|
| |
| |
| |
| | |
Issue #178
|
| |
| |
| |
| |
| |
| | |
when calling :meth:`.BatchOperations.create_foreign_key`. Pull
request courtesy Malte Marquarding.
- add tests
|
|\ \ |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
and so-called "schema" types such as Boolean, Enum within the batch
copy system; the CHECK constraint will not be "doubled" when the table is
copied, and additionally the inspection of the CHECK constraint for
its member columns will no longer fail with an attribute error.
fixes #249
- Added two new arguments
:paramref:`.Operations.batch_alter_table.reflect_args`
and :paramref:`.Operations.batch_alter_table.reflect_kwargs`, so that
arguments may be passed directly to suit the
:class:`~.sqlalchemy.schema.Table`
object that will be reflected.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
suit some very obscure use case where the ``revision_environment``
flag is set up, so that ``env.py`` is run when ``alembic revision``
is run even though autogenerate isn't specified. As this flag is
otherwise confusing, error messages are now raised if
``alembic revision`` is invoked with both ``--sql`` and
``--autogenerate`` or with ``--sql`` without
``revision_environment`` being set.
fixes #248
|
| |
| |
| |
| |
| |
| | |
``alembic downgrade`` and ``alembic history`` can be combined with
specific revisions as well, e.g. ``alembic upgrade ae10+3``, to produce
a migration target relative to the given exact version.
|
| |
| |
| |
| | |
to filter_for_lineage
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
but i guess it's OK
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
individual pages. the pages here are a little slim in the middle
but overall the one-page docs were getting extremely long.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
specific version directories are now also configurable to include
multiple, user-defined directories. When multiple directories exist,
the creation of a revision file with no down revision requires
that the starting directory is indicated; the creation of subsequent
revisions along that lineage will then automatically use that
directory for new files.
fixes #124
|
| |
| |
| |
| |
| |
| |
| |
| | |
down_revision and "dependencies". For migration traversal, the downrevs
we care about are the union of these two sets. however for location of nodes
and branch labeling, we look only at down_revsion. this works really well
and allows us to have mutually-dependent trees that can easily be itererated
independently of each other. docs are needed
|
| |
| |
| |
| |
| |
| |
| |
| | |
following it; this will be the norm in the case where parallel
branches refer to each other as dependencies.
this means we need to limit for from/to revisions based on current
heads / ancestors of those heads whenever we merge/unmerge.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
given the same name; for now it is assumed that the "index" is the
implicit one Postgreql generates. Future integration with
new SQLAlchemy 1.0 features will improve this to be more
resilient.
fixes #247
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
autogenerate will now place the "drop constraint" calls *before*
the "drop column" calls, so that columns involved in those constraints
still exist when the constraint is dropped.
fixes #247
|
| |
| |
| |
| | |
even need it but should be fine
|
| | |
|
| | |
|