summaryrefslogtreecommitdiff
path: root/CHANGES
diff options
context:
space:
mode:
authorMike Bayer <mike_mp@zzzcomputing.com>2011-11-27 19:05:39 -0500
committerMike Bayer <mike_mp@zzzcomputing.com>2011-11-27 19:05:39 -0500
commitf8fc2cab6995cf6639e0cc1998cfe691716746ab (patch)
tree7724b3524a75c4e3821bb9ef97417a2103731a81 /CHANGES
parent990ce0aa42bcf8b097d2c539661df998ddcce0fd (diff)
downloadalembic-f8fc2cab6995cf6639e0cc1998cfe691716746ab.tar.gz
- support for schema types in modify type
- add known status to CHANGES - google group - sa. prefix on modify type in autogenerate - rename_table
Diffstat (limited to 'CHANGES')
-rw-r--r--CHANGES87
1 files changed, 86 insertions, 1 deletions
diff --git a/CHANGES b/CHANGES
index a8b5568..14095f6 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1 +1,86 @@
-0.1 initial release.
+0.1.0
+=====
+- Initial release. Status of features:
+
+- Alembic is used in at least one production
+ environment, but should still be considered
+ alpha-level as of this release,
+ particularly in that many features are expected
+ to be missing / unimplemented.
+ The author asks that you *please* report all
+ issues, missing features, workarounds etc.
+ to the bugtracker, at
+ https://bitbucket.org/zzzeek/alembic/issues/new .
+
+- Postgresql and MS SQL Server environments
+ have been tested for several weeks in a production
+ environment. In particular, some involved workarounds
+ were implemented for automated dropping of columns
+ with SQL Server, which makes it extremely difficult
+ due to constraints, defaults being separate.
+
+ Other database environments not included among
+ those two have *not* been tested, *at all*. This
+ includes MySQL, Firebird, Oracle, Sybase. Adding
+ support for these backends is *very easy*, and
+ many directives may work already if they conform
+ to standard forms. Please report all missing/
+ incorrect behaviors to the bugtracker! Patches
+ are welcome here but are optional - please just
+ indicate the exact format expected by the target
+ database.
+
+- SQLite, as a backend, has almost no support for
+ schema alterations to existing databases. The author
+ would strongly recommend that SQLite not be used in
+ a migration context - just dump your SQLite database
+ into an intermediary format, then dump it back
+ into a new schema. For dev environments, the
+ dev installer should be building the whole DB from
+ scratch. Or just use Postgresql, which is a much
+ better database for non-trivial schemas.
+ Requests for full ALTER support on SQLite should be
+ reported to SQLite's bug tracker at
+ http://www.sqlite.org/src/wiki?name=Bug+Reports.
+ Requests for "please have SQLite rename the table
+ to a temptable then copy the data into a new table"
+ will be closed. Note that Alembic will at some
+ point offer an extensible API so that you can
+ implement commands like this yourself.
+
+- Well-tested directives include add/drop table, add/drop
+ column, including support for so-called "schema"
+ types, types which generate additional CHECK
+ constraints, i.e. Boolean, Enum. Other directives not
+ included here have *not* been strongly tested
+ in production, i.e. rename table, etc.
+
+- Both "online" and "offline" migrations have been strongly
+ production tested against Postgresql and SQL Server.
+
+- Modify column type/boolean is not as fully covered.
+ "Schema" types do add/drop the associated constraint
+ but this has not been widely tested, only in unit tests.
+
+- Many migrations are still outright missing, i.e.
+ create/add sequences, etc. As a workaround,
+ execute() can be used for those which are missing,
+ though posting of tickets for new features/missing
+ behaviors is strongly encouraged.
+
+- Autogenerate feature is implemented in a rudimentary
+ fashion. It's covered by unit and integration tests
+ and has had some basic rudimentary testing. The feature
+ has *not* been used in a production setting so is likely
+ missing lot of desirable behaviors. The
+ autogenerate feature only generates "sample" commands
+ which must be hand-tailored in any case, so this only
+ impacts the usefulness of the command, not overall
+ stability.
+
+- Support for tables in remote schemas,
+ i.e. "schemaname.tablename", is very poor.
+ Missing "schema" behaviors should be
+ reported as tickets, though in the author's
+ experience, migrations typically proceed only
+ within the default schema.