DESCRIPTION.rst 4.9 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980
  1. Alembic is a database migrations tool written by the author
  2. of `SQLAlchemy <http://www.sqlalchemy.org>`_. A migrations tool
  3. offers the following functionality:
  4. * Can emit ALTER statements to a database in order to change
  5. the structure of tables and other constructs
  6. * Provides a system whereby "migration scripts" may be constructed;
  7. each script indicates a particular series of steps that can "upgrade" a
  8. target database to a new version, and optionally a series of steps that can
  9. "downgrade" similarly, doing the same steps in reverse.
  10. * Allows the scripts to execute in some sequential manner.
  11. The goals of Alembic are:
  12. * Very open ended and transparent configuration and operation. A new
  13. Alembic environment is generated from a set of templates which is selected
  14. among a set of options when setup first occurs. The templates then deposit a
  15. series of scripts that define fully how database connectivity is established
  16. and how migration scripts are invoked; the migration scripts themselves are
  17. generated from a template within that series of scripts. The scripts can
  18. then be further customized to define exactly how databases will be
  19. interacted with and what structure new migration files should take.
  20. * Full support for transactional DDL. The default scripts ensure that all
  21. migrations occur within a transaction - for those databases which support
  22. this (Postgresql, Microsoft SQL Server), migrations can be tested with no
  23. need to manually undo changes upon failure.
  24. * Minimalist script construction. Basic operations like renaming
  25. tables/columns, adding/removing columns, changing column attributes can be
  26. performed through one line commands like alter_column(), rename_table(),
  27. add_constraint(). There is no need to recreate full SQLAlchemy Table
  28. structures for simple operations like these - the functions themselves
  29. generate minimalist schema structures behind the scenes to achieve the given
  30. DDL sequence.
  31. * "auto generation" of migrations. While real world migrations are far more
  32. complex than what can be automatically determined, Alembic can still
  33. eliminate the initial grunt work in generating new migration directives
  34. from an altered schema. The ``--autogenerate`` feature will inspect the
  35. current status of a database using SQLAlchemy's schema inspection
  36. capabilities, compare it to the current state of the database model as
  37. specified in Python, and generate a series of "candidate" migrations,
  38. rendering them into a new migration script as Python directives. The
  39. developer then edits the new file, adding additional directives and data
  40. migrations as needed, to produce a finished migration. Table and column
  41. level changes can be detected, with constraints and indexes to follow as
  42. well.
  43. * Full support for migrations generated as SQL scripts. Those of us who
  44. work in corporate environments know that direct access to DDL commands on a
  45. production database is a rare privilege, and DBAs want textual SQL scripts.
  46. Alembic's usage model and commands are oriented towards being able to run a
  47. series of migrations into a textual output file as easily as it runs them
  48. directly to a database. Care must be taken in this mode to not invoke other
  49. operations that rely upon in-memory SELECTs of rows - Alembic tries to
  50. provide helper constructs like bulk_insert() to help with data-oriented
  51. operations that are compatible with script-based DDL.
  52. * Non-linear, dependency-graph versioning. Scripts are given UUID
  53. identifiers similarly to a DVCS, and the linkage of one script to the next
  54. is achieved via human-editable markers within the scripts themselves.
  55. The structure of a set of migration files is considered as a
  56. directed-acyclic graph, meaning any migration file can be dependent
  57. on any other arbitrary set of migration files, or none at
  58. all. Through this open-ended system, migration files can be organized
  59. into branches, multiple roots, and mergepoints, without restriction.
  60. Commands are provided to produce new branches, roots, and merges of
  61. branches automatically.
  62. * Provide a library of ALTER constructs that can be used by any SQLAlchemy
  63. application. The DDL constructs build upon SQLAlchemy's own DDLElement base
  64. and can be used standalone by any application or script.
  65. * At long last, bring SQLite and its inablity to ALTER things into the fold,
  66. but in such a way that SQLite's very special workflow needs are accommodated
  67. in an explicit way that makes the most of a bad situation, through the
  68. concept of a "batch" migration, where multiple changes to a table can
  69. be batched together to form a series of instructions for a single, subsequent
  70. "move-and-copy" workflow. You can even use "move-and-copy" workflow for
  71. other databases, if you want to recreate a table in the background
  72. on a busy system.
  73. Documentation and status of Alembic is at http://alembic.zzzcomputing.com/