On 20/02/2009, at 11:58 PM, James Adam wrote:
While this works now, it is a hack which relies on Rails behaviour
that is not intentional.
Adding a column is a more elegant and robust hack, and the more
elegant the solution, the easier it will be to convince core to
integrate it, and this become a hack no more.
I can't argue with that statement.
Rails plugins & migrations generally seem pretty hacked up.
Basically there are two characteristics of migrations:
- They have some sort of order.
- But, some migrations can be applied in parallel - i.e. they don't
depend on some other migration. (i.e. most add_table migrations can be
run in any order)
Rails has introduced a lot of semantics that don't actually appear to
make much sense or even are that useful:
Being able to migrate plugins backwards is almost completely useless -
I've never used it. 50% of the code in migrations for me is a waste of
time (it should just be generated automatically if required). In many
cases migrating backwards is impossible anyway without data loss or
corruption.
Timestamped plugins is a complete mistake in my opinion. They
overcomplicate the issue. Why not just allow plugins with the same
order number. Generally, this suits the purpose required anyway i.e.
003_add_table_a.rb
003_add_table_b.rb
Wasn't the goal of timestamped migrations to allow multiple developers
to create migrations that don't clash? Is it the purpose of the
"number" to be unique id, or provide order? In my mind, it makes far
more sense for migrations to be ordered rather than indexed.
In the above situation, we can apply "003" migrations in any sequence
- "A" followed by "B" or "B" followed by "A". In the case they were
developed by separate developers, they can't possibly rely on each
other anyway...
In the database, you'd have a migration table that listed the full
name of the migration:
Migrations:
^ name ^
| 003_add_table_a |
| 003_add_table_b |
The way to apply new migrations is just to list all migrations in
sorted order, then only apply them if they are not already in the
migrations db.
Generally, I think for plugins, migrations can be simply copied across
to the main migrations directory, and everything will work as expected
with this kind of design. The current migrations code is completely
over engineered and for 99% of users does not provide a significant
benefit, and makes things that should be natural, more complex and non-
intuitive.
A lot of code could be reduced by simplifying migrations in this way.
Kind regards,
Samuel
_______________________________________________
Engine-Users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
