| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
``ondelete``, ``onupdate``, ``initially`` and ``deferrable``
attributes of :class:`.ForeignKeyConstraint` objects on
SQLAlchemy backends that support these on reflection
(as of SQLAlchemy 1.0.8 currently Postgresql for all four,
MySQL for ``ondelete`` and ``onupdate`` only). A constraint object
that modifies these values will be reported as a "diff" and come out
as a drop/create of the constraint with the modified values.
The fields are ignored for backends which don't reflect these
attributes (as of SQLA 1.0.8 this includes SQLite, Oracle, SQL Server,
others). fixes #317
|
| |
|
| |
|
|\
| |
| | |
The name has changed to bdist_wheel
|
|/
|
| |
...to fit with other setuptools configs
|
| |
|
|
|
|
|
|
| |
directive would be incorrectly rendered with the source table and
schema names in the argument list.
fixes #315
|
| |
|
|
|
|
|
|
| |
the original object passed in from autogenerate. In particular this
ensures that the diff structure from compare_metadata is fully backwards compatible
with no chance of synthesized objects.
|
|
|
|
|
| |
this provides for operation-specific handler functions.
docs are based on the example requested in references #313.
|
|
|
|
|
|
|
|
| |
duplicate revisions, some commands would fail to process the
version history correctly and end up with a KeyError. The fix
allows the versioning logic to proceed, however a clear error is
emitted later when attempting to update the alembic_version table.
fixes #314
|
|
|
|
|
|
| |
edits migration files using $EDITOR
- alter the edit command so that it accepts an argument in the same
way as ``alembic show``.
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Running ``alembic edit`` will open the latest revision in a text-editor.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
``alembic revision`` command, allowing ``depends_on`` to be
established at the command line level rather than having to edit
the file after the fact. ``depends_on`` identifiers may also be
specified as branch names at the command line or directly within
the migration file. The values may be specified as partial
revision numbers from the command line which will be resolved to
full revision numbers in the output file.
fixes #311
|
| |
| |
| |
| | |
references #173, references #119
|
| |
| |
| |
| | |
(cherry picked from commit b8c8dc581fcdef6490a5f082d1adc0f9f50f279d)
|
| |
| |
| |
| |
| |
| |
| | |
bog down the iteration algorithm working over redundant nodes for
millions of cycles. An internal adjustment has been
made so that duplicate nodes are skipped within this iteration.
fixes #310
|
| |
| |
| |
| |
| | |
put notes at the top of most of them
- consolidate EnvironmentContext / MigrationContext
|
| |
| |
| |
| | |
- ensure remaining name->constraint_name / table_name
|
| |
| |
| |
| |
| | |
from autogenerate; in the immediate sense this should help with
modelsmigrationsync tests
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
objects; the "diffs" is now a legacy system that is exported from
the ops. A new model of comparison/rendering/ upgrade/downgrade
composition that is cleaner and much more extensible is introduced.
- autogenerate is now extensible as far as database objects compared
and rendered into scripts; any new operation directive can also be
registered into a series of hooks that allow custom database/model
comparison functions to run as well as to render new operation
directives into autogenerate scripts.
- write all new docs for the new system
fixes #306
|
|/
|
|
| |
nose still works via run_tests.py.
|
|
|
|
| |
- warn for name changes
|
|
|
|
| |
- add missing translate for create_pk
|
|
|
|
|
|
|
|
|
| |
This is so that we can do a total open ended "*args, **kw" style translation
for the vast majority of use cases that are using alembic.op, without impacting
docstrings for the Operations class.
There is a risk here of impacting an application that is using Operations
directly instantitaed while using old names. We may still have to accommodate
that somehow.
|
|
|
|
|
|
|
| |
and :meth:`.BatchOperations.create_check_constraint`.
fixes #305
- table keyword arguments are copied from the original reflected table,
such as the "mysql_engine" keyword argument.
|
|
|
|
|
| |
portable to the name itself. so we don't need to handle this arg
explicitly.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- The internal system for Alembic operations has been reworked to now
build upon an extensible system of operation objects. New operations
can be added to the ``op.`` namespace, including that they are
available in custom autogenerate schemes. fixes #302
- The internal system for autogenerate been reworked to build upon
the extensible system of operation objects present in #302.
A new customization hook process_revision_directives is added
to allow manipulation of the autogen stream. Fixes #301
|
|
|
|
| |
the fix was committed in 229f8672.
|
| |
|
|
|
|
|
|
|
|
| |
versioning refactor in 0.7 as a more granular version of
:func:`.command.stamp`, now includes the "create the alembic_version
table if not present" step in the same way as the command version,
which was previously omitted.
fixes #300
|
|
|
|
| |
warnings
|
|
|
|
|
|
|
| |
"ondelete" would not render within the ``op.create_foreign_key()``
directive, even though they render within a full
``ForeignKeyConstraint`` directive.
fixes #298
|
| |
|
| |
|
|\
| |
| |
| | |
Fix typo in autogenerate documentation
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
| |
have the identical set of ancestor revisions would fail to be
upgradable, producing an assertion failure. Merge points were
previously assumed to always require at least an UPDATE in
alembic_revision from one of the previous revs to the new one,
however in this case, if one of the mergepoints has already
been reached, the remaining mergepoints have no row to UPDATE therefore
they must do an INSERT of their target version.
fixes #297
|
| |
|
|
|
|
|
|
|
|
| |
environment, but also present on the custom types themselves, by
supplying a method ``compare_against_backend``.
Added a new documentation section :ref:`compare_types` describing
type comparison fully.
fixes #296
|