[sqlalchemy] is sqlalchemy-migrate the right way to go?

2010-05-17 Thread Chris Withers

Hi All,

I want our production systems to start caring about the versions of 
their schemas. sqlalchemy-migrate was the first project I came across 
which addresses this. What other projects should I look at in this area, 
or is sqlalchemy-migrate the obvious choice?


If it is, how can I, in my application, check what version of the schema 
the current database is? (the idea being that the app will refuse to 
start unless the schema version is that expected by the app)


Related: how can I short circuit this when the database is empty and 
bump the schema version up to the latest for the app? (ie: dev 
instances, where the process is to blow the db away often so no need for 
migration)


cheers,

Chris

--
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.



Re: [sqlalchemy] is sqlalchemy-migrate the right way to go?

2010-05-17 Thread Michael Bayer

On May 17, 2010, at 1:13 PM, Chris Withers wrote:

 Hi All,
 
 I want our production systems to start caring about the versions of their 
 schemas. sqlalchemy-migrate was the first project I came across which 
 addresses this. What other projects should I look at in this area, or is 
 sqlalchemy-migrate the obvious choice?
 
 If it is, how can I, in my application, check what version of the schema the 
 current database is? (the idea being that the app will refuse to start unless 
 the schema version is that expected by the app)
 
 Related: how can I short circuit this when the database is empty and bump the 
 schema version up to the latest for the app? (ie: dev instances, where the 
 process is to blow the db away often so no need for migration)

sqlalchemy-migrate is the obvious choice.I am also developing a 
micro-migrations system called Alembic (http://bitbucket.org/zzzeek/alembic) in 
conjunction with my current work project but not all features have been 
implemented yet - its expected that I'll be getting them in a more polished 
state in the coming months.  The Migrate project can of course steal any and 
all desireable features and code from Alembic freely as I would like 
sqlalchemy-migrate to remain the default choice.

as for the related issue, I think its best that your setup provide a 
setup-app type of command which generates an initial schema, and embeds the 
current migrate version number.   Here's a snip of a related Pylons websetup.py:

from migrate.versioning.api import version_control, version, upgrade
from migrate.versioning.exceptions import DatabaseAlreadyControlledError

# Create the tables if they aren't there already
meta.Base.metadata.create_all(bind=meta.engine, checkfirst=True)

# setup migrate versioning table if not present
try:
latest_version = version(migrate)
version_control(pylons.config['sqlalchemy.url'], migrate, 
version=latest_version, echo=True)
except DatabaseAlreadyControlledError:
log.info(migrate table already present)

# do any migrate upgrades pending...
upgrade(pylons.config['sqlalchemy.url'], migrate, version=latest_version, 
echo=True)


The migrations system should only be used for changes to an existing schema.   
Other check this before running types of functionality can be accomplished 
similarly.

As a side note, I also have an elaborate monkeypatch to migrate to get it to 
work with transactional DDL.Simple support for transactional DDL is one of 
the goals of the new tool I am writing.   If you're not on Postgresql or 
MS-SQL, then you can't use transactional DDL anyway.

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.



Re: [sqlalchemy] is sqlalchemy-migrate the right way to go?

2010-05-17 Thread Chris Withers

Michael Bayer wrote:
sqlalchemy-migrate is the obvious choice.I am also developing a micro-migrations system called Alembic (http://bitbucket.org/zzzeek/alembic) 


If we start with sqlalchemy-migrate, do you reckon switching to Alembic 
when it's mature would be feasible?


Chris

--
Simplistix - Content Management, Batch Processing  Python Consulting
   - http://www.simplistix.co.uk

--
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.



Re: [sqlalchemy] is sqlalchemy-migrate the right way to go?

2010-05-17 Thread Michael Bayer
It's not clear that Alembic has real advantages over Migrate.  Its simpler for 
sure since it only is for SQLA 0.6 and up and doesn't attempt to do the crazy 
things Migrate does like versioning SQLite databases.   I'm going to attempt to 
handle branching (but already that means, ugly hex digest version numbers).
The transactional DDL and the very short ALTER constructs that don't require 
Table metadata are other advantages, but Migrate could have those same features 
(particularly if they decide to drop pre-0.6 support, which they probably 
cannot for some time).   

It also doesn't have any of the schema comparison stuff Migrate has, which 
seems to be the kind of thing people want (Ken's request is not the first I've 
heard). Migrate could improve a lot on that feature if they use the new 
Inspector interface in 0.6.

So its hard to say at the moment.It wouldn't be too hard to move from one 
to the other except that you'd probably start back at version 1 and not try to 
re-use old version files (which again appears to be heresy in some migration 
circles).

  



On May 17, 2010, at 7:50 PM, Chris Withers wrote:

 Michael Bayer wrote:
 sqlalchemy-migrate is the obvious choice.I am also developing a 
 micro-migrations system called Alembic (http://bitbucket.org/zzzeek/alembic) 
 
 If we start with sqlalchemy-migrate, do you reckon switching to Alembic when 
 it's mature would be feasible?
 
 Chris
 
 -- 
 Simplistix - Content Management, Batch Processing  Python Consulting
   - http://www.simplistix.co.uk
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 sqlalchemy group.
 To post to this group, send email to sqlalch...@googlegroups.com.
 To unsubscribe from this group, send email to 
 sqlalchemy+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/sqlalchemy?hl=en.
 

-- 
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.