SubscribeI set up the PyMigrate files on http://code.google.com/p/pymigrate/ without any tests because PyMigrate at that time was a prototype. I’ve created and refactored PyMigrate into a solid form and there the tests are included and these will continue to be maintained.
I haven’t written the tests to the library files yet because Pete’s comment about other libraries, and the sqlalchemy-migrate egg got me thinking. I’m thinking that since SqlAlchemy already supports multiple database types why should I re-invent that using a multitude of plug-ins? Why should I take on the maintenance responsibilities for doing so.
Nay I say. I’m thinking about using SqlAlchecemy exclusively, and it can deal with all the database types and queries. I’ll just create an adapter to work with it from my format.
Thoughts?
Tags: PyMigrate
Entries
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?
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.
This is shaping up to be really cool!
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 ?
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.
why not say, metadata(create_engine(”your://database”)).reflect_all() ? no model building.
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.