Debating web development toolsets

[Christopher Browne]

On Jan 8, 2008 1:58 AM, Ian Petersen <ispeters-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> 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.

The trouble is that sometimes you have extra things going on, such as
database replication.

What I hear is that if you are using such, you pretty much have to
turn it off when doing a RoR application upgrade that might have any
impact on the database schema, as RoR wants to go in and make schema
changes as It likes, on Its schedule.

If there's *any* reason (like that) why you'd want to keep schema
changes under sorts of control that don't fall into how RoR operates,
evidently disappointment lingers in the wings...

Well, and the whole "who would ever actually need a composite primary
key?" thing nicely demonstrates both:
a) Lack of forethought, and
b) Lack of willingness to listen

The former flaw isn't individually fatal, but when combined together,
they spell "doom" to me.
-- 
http://linuxfinances.info/info/linuxdistributions.html
"The definition of insanity is doing the same thing over and over and
expecting different results."  -- assortedly attributed to Albert
Einstein, Benjamin Franklin, Rita Mae Brown, and Rudyard Kipling
--
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