Comments on: I’ve updated the PyMigrate test

By: ScottK

ScottK — Sat, 14 Feb 2009 21:18:58 +0000

I’ve begun to look at integrating SA and see that SA needs to be aware of the table structure. From my tests I think that SqlAlchemy is the way to go as it supports so many different database types.

My test units have shown that SA needs to know the existing database constructs. I just need to implement the correct conversions. One of the first thing that’s bothering me initially is that calling Column(name, String) in MySql errors the database where as Column(name, Sting(50)) works fine.

It may be something I have to deal with on my end if not in SA.

By: mike bayer

mike bayer — Sat, 14 Feb 2009 20:32:12 +0000

why not say, metadata(create_engine(”your://database”)).reflect_all() ? no model building.

By: ScottK

ScottK — Sat, 14 Feb 2009 12:48:02 +0000

I hadn’t learned of sqlalchemy-migrate till just a few days prior to releasing PyMigrate. So I basically had a working system.

After looking at sqlalchemy-pymigrate I didn’t like how I would have to learn sqlalchemy to format the tables as a user. Even then it seemed like a lot of work to create a table by fist building the model so SA could map it.

Truth be told though, as long as the migration format set-up is easy for the user, I’m ok with either system. I’ll look at it again and see if maybe I can help out with it.

By: mike bayer

mike bayer — Sat, 14 Feb 2009 08:13:29 +0000

why not just contribute to the Migrate project ? They could definitely use the help. We’ve added new compilable DDL constructs in SQLA 0.6 that they’re going to want to adapt to (and you will too if you stay on SQLA as your base), so there’s work to be done all around.

Inventing a whole new PyMigrate, which is going to use SQLAlchemy just like migrate anyway, seems like a huge duplication of effort ?

By: Trevor

Trevor — Fri, 13 Feb 2009 19:47:32 +0000

This is shaping up to be really cool!

By: ScottK

ScottK — Fri, 13 Feb 2009 18:42:02 +0000

Stay out of my head!!! Damn it!

At first I need an plug-in that does all the formatting for the user/architecture without their knowledge. Sso SQLAlchemy my fit this bill. The user’s migrations would just need to fit the format.

I have thought about how to do this with rolling my own db API, hence the stay out my head and good point. I’ll make the class easily extend-able so that if a user wants to roll their own they can substitute their own database integration.

By: Trevor

Trevor — Fri, 13 Feb 2009 17:55:31 +0000

I haven’t checked out your codebase but are you thinking of keeping SqlAlchemy exclusively for the ORM for this? Maybe instead of a pluggable architecture for database types, perhaps the option to pick and roll your own ORM?