- prepare for release 0.4.0
This commit is contained in:
jan.dittberner
parent
32aeb8e95e
commit
b4ef79dc04
@ -1,3 +1,7 @@
|
||||
0.4.0
|
||||
- SA 0.4.0 compatibility thanks to Christian Simms
|
||||
- all unit tests are working now (with sqlalchemy >= 0.3.10)
|
||||
|
||||
0.3
|
||||
- SA 0.3.10 compatibility
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ migrate.changeset
|
||||
|
||||
Importing ``migrate.changeset`` adds some new methods to existing SA objects, as well as creating functions of its own. Most operations can be done either by a method or a function. Methods match SA's existing API and are more intuitive when the object is available; functions allow one to make changes when only the name of an object is available (for example, adding a column to a table in the database without having to load that table into Python).
|
||||
|
||||
Changeset operations can be used independently of Migrate's `versioning system`_.
|
||||
Changeset operations can be used independently of SQLAlchemy Migrate's `versioning system`_.
|
||||
|
||||
For more information, see the generated documentation for `migrate.changeset`_.
|
||||
|
||||
@ -81,7 +81,7 @@ Rename an index, given an SQLAlchemy ``Index`` object::
|
||||
Constraint
|
||||
==========
|
||||
|
||||
SQLAlchemy supports creating/dropping constraints at the same time a table is created/dropped. Migrate adds support for creating/dropping primary/foreign key constraints independently.
|
||||
SQLAlchemy supports creating/dropping constraints at the same time a table is created/dropped. SQLAlchemy Migrate adds support for creating/dropping primary/foreign key constraints independently.
|
||||
|
||||
Primary key constraints::
|
||||
|
||||
@ -91,7 +91,7 @@ Primary key constraints::
|
||||
# Drop the constraint
|
||||
cons.drop()
|
||||
|
||||
Note that Oracle requires that you state the name of the primary key constraint to be created/dropped. Migrate will try to guess the name of the PK constraint for other databases, but if it's something other than the default, you'll need to give its name::
|
||||
Note that Oracle requires that you state the name of the primary key constraint to be created/dropped. SQLAlchemy Migrate will try to guess the name of the PK constraint for other databases, but if it's something other than the default, you'll need to give its name::
|
||||
|
||||
PrimaryKeyConstraint(col1,col2,name='my_pk_constraint')
|
||||
|
||||
|
||||
@ -5,11 +5,11 @@ Migrate
|
||||
Download
|
||||
========
|
||||
|
||||
Migrate builds on SQLAlchemy_, so you should install that first.
|
||||
SQLAlchemy-Migrate builds on SQLAlchemy_, so you should install that first.
|
||||
|
||||
You can get the latest version of Migrate from the `cheese shop`_, or via easy_install_::
|
||||
You can get the latest version of SQLAlchemy Migrate from the `cheese shop`_, or via easy_install_::
|
||||
|
||||
easy_install migrate
|
||||
easy_install sqlalchemy-migrate
|
||||
|
||||
You should now be able to use the *migrate* command from the command line::
|
||||
|
||||
@ -17,21 +17,21 @@ You should now be able to use the *migrate* command from the command line::
|
||||
|
||||
This should list all available commands. *migrate help COMMAND* will display more information about each command.
|
||||
|
||||
If you'd like to be notified when new versions of migrate are released, subscribe to `migrate-announce`_.
|
||||
If you'd like to be notified when new versions of SQLAlchemy Migrate are released, subscribe to `migrate-announce`_.
|
||||
|
||||
.. _easy_install: http://peak.telecommunity.com/DevCenter/EasyInstall#installing-easy-install
|
||||
.. _sqlalchemy: http://www.sqlalchemy.org/download.myt
|
||||
.. _`cheese shop`: http://www.python.org/pypi/migrate
|
||||
.. _`cheese shop`: http://www.python.org/pypi/sqlalchemy-migrate
|
||||
.. _`migrate-announce`: http://groups.google.com/group/migrate-announce
|
||||
|
||||
Development
|
||||
===========
|
||||
|
||||
Migrate's Subversion_ repository is at http://erosson.com/migrate/svn/
|
||||
Migrate's Subversion_ repository is at http://sqlalchemy-migrate.googlecode.com/svn/
|
||||
|
||||
To get the latest trunk::
|
||||
|
||||
svn co http://erosson.com/migrate/svn/migrate/trunk
|
||||
svn co http://sqlalchemy-migrate.googlecode.com/svn/trunk
|
||||
|
||||
Patches should be submitted as Trac tickets.
|
||||
|
||||
|
||||
@ -1,13 +1,15 @@
|
||||
=======
|
||||
Migrate
|
||||
=======
|
||||
==================
|
||||
SQLAlchemy Migrate
|
||||
==================
|
||||
SQLAlchemy schema change management
|
||||
-----------------------------------
|
||||
|
||||
Inspired by Ruby on Rails' migrations, Migrate provides a way to deal with database schema changes in SQLAlchemy_ projects.
|
||||
Inspired by Ruby on Rails' migrations, SQLAlchemy Migrate provides a way to deal with database schema changes in SQLAlchemy_ projects.
|
||||
|
||||
Migrate was started as part of `Google's Summer of Code`_ by Evan Rosson, mentored by Jonathan LaCour.
|
||||
|
||||
The project was taken over by a small group of volunteers when Evan had no free time for the project. It is now hosted as a `Google Code project`_. During the hosting change the project was renamed to SQLAlchemy Migrate.
|
||||
|
||||
- Download_
|
||||
|
||||
- Documentation:
|
||||
@ -17,6 +19,7 @@ Migrate was started as part of `Google's Summer of Code`_ by Evan Rosson, mentor
|
||||
* Changeset_: Database-independent schema changes; ALTER TABLE with SQLAlchemy
|
||||
|
||||
.. _`google's summer of code`: http://code.google.com/soc
|
||||
.. _`Google Code project`: http://code.google.com/p/sqlalchemy-migrate
|
||||
.. _download: download.html
|
||||
.. _versioning: versioning.html
|
||||
.. _changeset: changeset.html
|
||||
|
||||
@ -35,7 +35,7 @@ The database is specified as a `SQLAlchemy database url`_.
|
||||
|
||||
We can have any number of databases under this repository's version control.
|
||||
|
||||
Each schema has a version that Migrate manages. Each change script applied to the database increments this version number. You can see a database's current version::
|
||||
Each schema has a version that SQLAlchemy Migrate manages. Each change script applied to the database increments this version number. You can see a database's current version::
|
||||
|
||||
% migrate db_version sqlite:///project.db my_repository
|
||||
0
|
||||
@ -111,7 +111,7 @@ You should be very careful about importing files from the rest of your applicati
|
||||
|
||||
Commit the change script
|
||||
------------------------
|
||||
Now that our script is done, we'll commit it to our repository. Committed scripts are considered 'done' - once a script is committed, it is moved into the repository, the change script file 'disappears', and your change script can be applied to a database. Once a script is committed, Migrate expects that the SQL the script generates will not change. (As mentioned above, this may be a bad assumption when importing files from your application!)
|
||||
Now that our script is done, we'll commit it to our repository. Committed scripts are considered 'done' - once a script is committed, it is moved into the repository, the change script file 'disappears', and your change script can be applied to a database. Once a script is committed, SQLAlchemy Migrate expects that the SQL the script generates will not change. (As mentioned above, this may be a bad assumption when importing files from your application!)
|
||||
|
||||
Change scripts should be tested before they are committed. Testing a script will run its upgrade() and downgrade() functions on a specified database; you can ensure the script runs without error. You should be testing on a test database - if something goes wrong here, you'll need to correct it by hand. If the test is successful, the database should appear unchanged after upgrade() and downgrade() run.
|
||||
|
||||
@ -154,7 +154,7 @@ Writing change scripts
|
||||
|
||||
By default, change scripts may do anything any other SQLAlchemy program can do.
|
||||
|
||||
Migrate extends SQLAlchemy with several operations used to change existing schemas - ie. ALTER TABLE stuff. See changeset_ documentation for details.
|
||||
SQLAlchemy Migrate extends SQLAlchemy with several operations used to change existing schemas - ie. ALTER TABLE stuff. See changeset_ documentation for details.
|
||||
|
||||
.. _changeset: changeset.html
|
||||
|
||||
@ -229,7 +229,7 @@ Sometimes you need to write code for a specific database. Migrate scripts can ru
|
||||
.sql scripts
|
||||
------------
|
||||
|
||||
You might prefer to write your change scripts in SQL, as .sql files, rather than as Python scripts. Migrate can work with that::
|
||||
You might prefer to write your change scripts in SQL, as .sql files, rather than as Python scripts. SQLAlchemy Migrate can work with that::
|
||||
|
||||
% migrate version my_repository
|
||||
10
|
||||
@ -242,11 +242,11 @@ You might prefer to write your change scripts in SQL, as .sql files, rather than
|
||||
|
||||
Here, two scripts are given, one for each *operation*, or function defined in a Python change script - upgrade and downgrade. Both are specified to run with Postgres databases - we can commit more for different databases if we like. Any database defined by SQLAlchemy may be used here - ex. sqlite, postgres, oracle, mysql...
|
||||
|
||||
For every .sql script added after the first, we must specify the version - if you don't enter a version to commit, Migrate assumes that commit is for a new version.
|
||||
For every .sql script added after the first, we must specify the version - if you don't enter a version to commit, SQLAlchemy Migrate assumes that commit is for a new version.
|
||||
|
||||
Python API
|
||||
==========
|
||||
All commands available from the command line are also available for your Python scripts by importing `migrate.versioning.api`_. See the `migrate.versioning.api`_ documentation for a list of functions; function names match equivalent shell commands. You can use this to help integrate Migrate with your existing update process.
|
||||
All commands available from the command line are also available for your Python scripts by importing `migrate.versioning.api`_. See the `migrate.versioning.api`_ documentation for a list of functions; function names match equivalent shell commands. You can use this to help integrate SQLAlchemy Migrate with your existing update process.
|
||||
|
||||
For example, the following commands are similar:
|
||||
|
||||
|
||||
4
setup.py
4
setup.py
@ -9,7 +9,7 @@ except ImportError:
|
||||
|
||||
setup(
|
||||
name = "sqlalchemy-migrate",
|
||||
version = "0.4.0dev",
|
||||
version = "0.4.0",
|
||||
packages = find_packages(exclude=['test*']),
|
||||
scripts = ['shell/migrate'],
|
||||
include_package_data = True,
|
||||
@ -20,7 +20,7 @@ Inspired by Ruby on Rails' migrations, Migrate provides a way to deal with datab
|
||||
Migrate extends SQLAlchemy to have database changeset handling. It provides a database change repository mechanism which can be used from the command line as well as from inside python code.
|
||||
""",
|
||||
|
||||
install_requires = ['sqlalchemy >= 0.4.0'],
|
||||
install_requires = ['sqlalchemy >= 0.3.10'],
|
||||
setup_requires = ['py >= 0.9.0-beta'],
|
||||
dependency_links = [
|
||||
"http://codespeak.net/download/py/",
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user