[Rails-core] some (long) thoughts on migrations

[Rick Bradley]

* Kevin Clark (kevin.clark at gmail.com) [060220 14:54]:
> The problem is the dependence tree. If you do it with timestamps, by
> inserting your own migrations you may change things later migrations
> depend on. Similarly, we lose the simplicity of VER#_description
> because you wouldn't be able to use filesystem timestamps which would
> break in a variety of cases.

The dependence tree is actually linear (hence one of the problems I was
dragging on about :-), but your point is taken.  If we were just talking
code then the conflicts are the same as an SVN conflict resolution,
which happens from time to time -- but we're not, the database is
involved.  With migrations one would have to back out the migration
(i.e., rake migrate to a prior version) then sort out the problems, then
migrate forward.  Actually the more I think about it the more it really
is like an SVN conflict merge.

On your second point I think you're right that there's a pretty baby in
the bathwater, being able to do rake migrate VERSION=n and having the
file's named with the version numbers are both good features.

I'm not necessarily recommending the adoption of an epoch timestamp
version number instead of a natural number version, but I might toy with
it at home if I can get a chance soon.

Rick
-- 
 http://www.rickbradley.com    MUPRN: 738
                       |  and grab content, which
   random email haiku  |  you see happening in the
                       |  "window" to the right.