From: Mike Bayer Date: Sun, 8 Jul 2012 22:45:10 +0000 (-0400) Subject: more edits X-Git-Tag: rel_0_3_6~13 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c91f95adea4e7ed9b0884bf1a6d5602b00eb63c2;p=thirdparty%2Fsqlalchemy%2Falembic.git more edits --- diff --git a/README.rst b/README.rst index 34c72b8b..b3ff87a7 100644 --- a/README.rst +++ b/README.rst @@ -61,14 +61,17 @@ The goals of Alembic are: 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. 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 + has almost no support for table or column alteration, and this is likely + intentional. Alembic's design + is kept simple by not contorting it's core API around these limitations, + understanding that SQLite is simply not intended to support schema + changes. While Alembic's architecture can support SQLite's workarounds, 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. + to implement and test, until the SQLite developers decide + to provide a fully working version of ALTER, it's still vastly preferable + to use Alembic, or any migrations tool, with databases that + are designed to work under the assumption of in-place schema migrations + taking place. Documentation and status of Alembic is at http://readthedocs.org/docs/alembic/.