revise the readme re: sqlite

diff --git a/README.rst b/README.rst
index 1638b4ea065de4b461523c0f564b0ae67f5cd98c..34c72b8b33d93c6ab096c66a0b6f4cdaf77e1f6e 100644 (file)
--- a/README.rst
+++ b/README.rst
@@ -2,9 +2,9 @@ Alembic is a new database migrations tool, written by the author
 of `SQLAlchemy <http://www.sqlalchemy.org>`_.  A migrations tool
 offers the following functionality:
 
-* Can emit ALTER statements to a database in order to change 
+* Can emit ALTER statements to a database in order to change
   the structure of tables and other constructs
-* Provides a system whereby "migration scripts" may be constructed; 
+* Provides a system whereby "migration scripts" may be constructed;
   each script indicates a particular series of steps that can "upgrade" a
   target database to a new version, and optionally a series of steps that can
   "downgrade" similarly, doing the same steps in reverse.
@@ -12,7 +12,7 @@ offers the following functionality:
 
 The goals of Alembic are:
 
-* Very open ended and transparent configuration and operation.   A new 
+* Very open ended and transparent configuration and operation.   A new
   Alembic environment is generated from a set of templates which is selected
   among a set of options when setup first occurs. The templates then deposit a
   series of scripts that define fully how database connectivity is established
@@ -20,11 +20,11 @@ The goals of Alembic are:
   generated from a template within that series of scripts. The scripts can
   then be further customized to define exactly how databases will be
   interacted with and what structure new migration files should take.
-* Full support for transactional DDL.   The default scripts ensure that all 
+* Full support for transactional DDL.   The default scripts ensure that all
   migrations occur within a transaction - for those databases which support
   this (Postgresql, Microsoft SQL Server), migrations can be tested with no
   need to manually undo changes upon failure.
-* Minimalist script construction.  Basic operations like renaming 
+* Minimalist script construction.  Basic operations like renaming
   tables/columns, adding/removing columns, changing column attributes can be
   performed through one line commands like alter_column(), rename_table(),
   add_constraint(). There is no need to recreate full SQLAlchemy Table
@@ -43,7 +43,7 @@ The goals of Alembic are:
   migrations as needed, to produce a finished migration. Table and column
   level changes can be detected, with constraints and indexes to follow as
   well.
-* Full support for migrations generated as SQL scripts.   Those of us who 
+* Full support for migrations generated as SQL scripts.   Those of us who
   work in corporate environments know that direct access to DDL commands on a
   production database is a rare privilege, and DBAs want textual SQL scripts.
   Alembic's usage model and commands are oriented towards being able to run a
@@ -52,20 +52,23 @@ The goals of Alembic are:
   operations that rely upon in-memory SELECTs of rows - Alembic tries to
   provide helper constructs like bulk_insert() to help with data-oriented
   operations that are compatible with script-based DDL.
-* Non-linear versioning.   Scripts are given UUID identifiers similarly 
+* Non-linear versioning.   Scripts are given UUID identifiers similarly
   to a DVCS, and the linkage of one script to the next is achieved via markers
   within the scripts themselves. Through this open-ended mechanism, branches
   containing other migration scripts can be merged - the linkages can be
   manually edited within the script files to create the new sequence.
-* Provide a library of ALTER constructs that can be used by any SQLAlchemy 
+* Provide a library of ALTER constructs that can be used by any SQLAlchemy
   application. The DDL constructs build upon SQLAlchemy's own DDLElement base
   and can be used standalone by any application or script.
 * Don't break our necks over SQLite's inability to ALTER things.   SQLite
-  has almost no support for table or column alteration.   This is by
-  design by the SQLite developers, so Alembic foregoes implementing
-  awkward and poorly-functional workarounds for this platform.
-  If you're serious about schema migrations, use a database that's 
-  just as serious!
+  has almost no support for table or column alteration.   Alembic's design
+  is kept simple by not contorting it's core API around these limitations.
+  Alembic's architecture can support SQLite's workarounds however, and
+  we will support these features provided someone takes the initiative
+  to implement and test.  However, until the SQLite developers decide
+  to implment full support for ALTER, it's still vastly preferable
+  to use Alembic, or any migrations tool, with a database that supports
+  ALTER fully.
 
 Documentation and status of Alembic is at http://readthedocs.org/docs/alembic/.