Debating web development toolsets

Ian Petersen ispeters-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Tue Jan 8 06:58:34 UTC 2008


On Jan 7, 2008 10:53 PM, Christopher Browne <cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> 100% agreed.
>
> All reports I see are that RoR defines a data access model that pretty
> much precludes any sort of "managed version migration."

I wonder if you could expand on that.  One of the coolest things that
Rails brings to the table is database migrations.  Basically, you
write a little script that has an "up" method and a "down" method for
each change that you make to the db.  To bring the db up to date, you
just do "rake migrate", or something.  (For those not in the know,
rake is a make-like tool written in Ruby--might be worth checking out
next time you get bitten by a tab-that's-not-a-tab.)  The migration
scripts can be as simple as table creation statements, but they're
written in Ruby so if you need to do backflips to get your db from
version n to n + 1, you have a Turing-complete language at your
disposal with which to do the flips.

I guess what I'm saying is, either you mean something else by "managed
version migration", or the reports you read have misunderstood one of
Rails' strengths.  On the other hand, maybe you're talking about the
fact that ActiveRecord assumes that all db records have an
auto-incrementing integer as the primary key.  This can be worked
around, so long as the true primary key is only one column
wide--otherwise you're SOL.  If that's what you mean, then I
agree--DHH has some strange opinions on database design.

Ian

-- 
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list