Debating web development toolsets

[Myles Braithwaite]

The Rails database migration is only really good in development pass  
that you are doing SQL commands on your production.

On 8-Jan-08, at 9:34 AM, Christopher Browne wrote:

> 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

--
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