In any case, I’d recommend anyone not managing their data migration to reach for the nearest solution and just start doing it already!.

In Affle, where we have many platforms, we use our own python script instead of Rails Migrations. The important thing is, migration *is* managed.

Yes you’re right. SqlAlchemy has migrations support through a third-party library called Migrate (http://erosson.com/migrate/trac/). But Django doesn’t use SQLAlchemy for ORM. It uses its own ORM layer.

And swapping SQLAlchemy in place of the Django ORM is not a trivial task. The speed gained through other means would be lost if you did. There’s a subversion branch to make this step easier.

The beautiful thing about Django’s template system is it has been designed for designers in mind – the default template language features are kept at a bare minimum. Expecting a designer to write Python/Ruby/PHP code does not make sense.

There are only two basic constructs in the template system: {{ variables }} and {% block_tags %}.

http://www.djangoproject.com/documentation/templates/ -> takes 15 mins to grasp whether you’re a programmer or not. But ask your designer to write Ruby and he’s certainly going to give you the look which you don’t wanna see :)

And the other thing is if you didn’t like the naming that they use, you can define your own block_tags in Python and then make the job easier for your designers.

But if you’re a developer/designer, I would imagine the idea of restricting you to a template language might sound like a move to cripple you.

A lot of it has to do with how these projects evolved. Django was developed inside the web division of a newspaper company. They typically would have a lot of designers in such teams, and a lot of computer-illiterate authors contributing the content – articles, news reports. The cool Admin system is also tailored to this scenario.

I knew Rails had Migrations but I didn’t realise that people actually use Schema Migrations to write the first version of the schema as pointed out by you at BarCamp (and definitely calling it ‘Migration’ doesn’t make sense for that use case!).

As far as Django is concerned, Rails-like Schema Migrations support is on its way. It was actually a Google Summer of Code project but the student who took up the project didn’t deliver. So someone else is rewriting the whole thing again because the previous codebase is apparently unusable. But the main purpose of this is only to help you to migrate the DB schema without writing SQL (atleast for simple CRUD tasks, the SQL required for which can be easily wrapped in helper Python functions). For complex migrations, there’s always an extremely easy way to run hand-written SQL in Django.

@Choon Keat: Fixed :P. Ahh… But Harish didn’t seem to realize that Rails had migrations :x

I have no experience in that test suite as the testing portion is left to my colleague. Will feedback once I gather my hands on that info.

CakePhp is a great framework as far as I am concern. Anyway, I had taken a look at barcampsg and it sound really cool. How do I get onto the bandwagon?

Hmm… migrations would’ve been swell for PHP crowd, but I believe Python has a similar schema version control… part of SQLxxx can’t remember

Here’s the link: http://cakeforge.org/projects/testsuite/

Cheers,

Michael Cheng