On Jan 6, 6:09 pm, "Daniel N" <has....@gmail.com
> One of the real issues I've found with classic migrations is that models
> change, but when a migration is run forward from 0, the migrations assume
> that it's all good.
The solution to this is to stop using your models in your migrations.
If I have a migration that needs to create, alter or remove a record,
I write the raw SQL INSERT or UPDATE statement to do that. There's no
guarantee that the model will work, or even be around and called the
same thing when the migration is run. If, for some reason, I really
want a model, I write a one-off class, and have it in-line with the
On Jan 6, 6:15 pm, Adam French <afcoo...@gmail.com
> I've been burned by migrations which add in data. It's better (IMHO)
> to create a rake task that creates default data in your database,
> rather than to use migrations for this.
We have several migrations that need to alter data as part of a schema
change. A rake task can't be versioned the same way as a migration,
and there's know way to know if the rake task has already been run.
Inserting default data is a different beast altogether.
On Jan 6, 10:15 pm, Sam Smoot <ssm...@gmail.com
> I'd like to support both types of migrations.
> The AR-type migrations are now in DM as of last week.
Sam, I saw these and started playing with them. They're still missing
a few critical features, like versioning and creating indexes. I
started to work on it yesterday, but the current core DM code doesn't
seem to facilitate the adding of additional indexes after the table
has already been created. The other features also seem difficult to
implement when relying on DM::Mappings::Table & ::Column. I was
thinking of pulling all the sql CREATE TABLE and ALTER TABLE parts
into a migrations module, and having DM::Base#automigrate! use it
instead. What are your thoughts on this?