summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorjan.dittberner <unknown>2008-02-14 21:07:25 +0000
committerjan.dittberner <unknown>2008-02-14 21:07:25 +0000
commitb4ef79dc043740a3547d812da7517c259406bd84 (patch)
treee826414396e194d563a1f9e3d61d50912633f96f
parent32aeb8e95efc78d6b947548c430c2475ccee2962 (diff)
downloadsqlalchemy-migrate-b4ef79dc043740a3547d812da7517c259406bd84.tar.gz
- prepare for release 0.4.0
-rw-r--r--CHANGELOG4
-rw-r--r--docs/changeset.rst6
-rw-r--r--docs/download.rst14
-rw-r--r--docs/index.rst11
-rw-r--r--docs/versioning.rst12
-rw-r--r--setup.py4
6 files changed, 29 insertions, 22 deletions
diff --git a/CHANGELOG b/CHANGELOG
index 7d962b2..6d8de83 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -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
diff --git a/docs/changeset.rst b/docs/changeset.rst
index 3746cfa..93932a0 100644
--- a/docs/changeset.rst
+++ b/docs/changeset.rst
@@ -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')
diff --git a/docs/download.rst b/docs/download.rst
index 88bdf20..dc6c1a5 100644
--- a/docs/download.rst
+++ b/docs/download.rst
@@ -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.
diff --git a/docs/index.rst b/docs/index.rst
index 568d2eb..04f9893 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -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
diff --git a/docs/versioning.rst b/docs/versioning.rst
index ce18526..0657228 100644
--- a/docs/versioning.rst
+++ b/docs/versioning.rst
@@ -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:
diff --git a/setup.py b/setup.py
index 882e47a..de7d806 100644
--- a/setup.py
+++ b/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/",