Rails - Jul 2006 - "throwing out the old": does Rails really not support...

Frankly I''m losing tolerance for the MS "stack."  And
I''m intrigued by
Rails.  But in my outfit I''m not only the web person, but also the 
application person and the DBA.  So when I read that Rails doesn''t want
to handle things like "compound keys" I blew right by those claims, 
thinking, "no way."

But before I go deeper, I should ask: does Rails really prefer to stay 
out of environments like mine where complex PKs and FKs, stored 
procedures, and table names that aren''t always drawn from language 
(plural vs singular names) are deeply embedded in our infrastructure? 
Do people like me in places like mine just stay out of Rails?

Thanks all.

-- 
Posted via http://www.ruby-forum.com/.

Frank -

Rails is pretty opinionated.  This is a good thing starting from scratch,
because you get a lot ''for free'' by following the conventions.
But if
you''ve got a legacy DB like you describe, you''re not going to
be able to
follow those conventions... and you''re going to have to do more work to
get
Rails to work with your system, if it''s even possible.  It might
require
more change than it is worth.

So at the risk of pissing off the fanboys: I think Rails is a great
framework that pretty much forces me to be a more agile programmer... and
that agility seems to be directly opposed to the sort of behemoth legacy
system you are describing.  You might be able to do it, but you''d be
fighting Rails instead of playing to its strengths.

 - foobario



On 7/22/06, Frank Burleigh <fburleigh@gmail.com>
wrote:
>
> Frankly I''m losing tolerance for the MS "stack."  And
I''m intrigued by
> Rails.  But in my outfit I''m not only the web person, but also the
> application person and the DBA.  So when I read that Rails doesn''t
want
> to handle things like "compound keys" I blew right by those
claims,
> thinking, "no way."
>
> But before I go deeper, I should ask: does Rails really prefer to stay
> out of environments like mine where complex PKs and FKs, stored
> procedures, and table names that aren''t always drawn from language
> (plural vs singular names) are deeply embedded in our infrastructure?
> Do people like me in places like mine just stay out of Rails?
>
> Thanks all.
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060723/e8207836/attachment.html

On Sun Jul 23, 2006 at 02:28:30AM +0200, Frank Burleigh
wrote:
> Frankly I''m losing tolerance for the MS "stack."  And
I''m intrigued by
> Rails.  But in my outfit I''m not only the web person, but also the
> application person and the DBA.  So when I read that Rails doesn''t
want
> to handle things like "compound keys" I blew right by those
claims,
> thinking, "no way."
> 
> But before I go deeper, I should ask: does Rails really prefer to stay 
> out of environments like mine where complex PKs and FKs, stored 
> procedures, and table names that aren''t always drawn from language
> (plural vs singular names) are deeply embedded in our infrastructure? 
> Do people like me in places like mine just stay out of Rails?
much of the ''magic'' in activerecord relies on convention -
columns automagically mapped to object attributes, integer FKs pointing to
another tables auto-generated integer PK automagically enabling a
"belongs_to" association, or contraints, getting nice form error
messages for free, by using the model validations rather than doing things in
the db.

its not that its impossible, its just creating more work for yourself: making
sure the db exceptions get passed properly through, and adding hash attributes
to a bunch of app code to explain your unconventional schema. one reward for the
suggested conformity is the ability to do everything from one place, and in
ruby...another being you can easily switch between db engines, OS''s,
web servers...since apache/mongrel/lighttpd and sqlite/postgres/mysql/oracle are
just being used as default-configuration off-the-shell tools that you didnt
invest time moving your application logic down into..

i think that explains the ''rails way''...

On Sat Jul 22, 2006 at 05:42:30PM -0700, foobario wrote:
> Frank -
> 
> Rails is pretty opinionated.  This is a good thing starting from scratch,
> because you get a lot ''for free'' by following the
conventions.  But if
> you''ve got a legacy DB like you describe, you''re not
going to be able to
> follow those conventions... and you''re going to have to do more
work to get
> Rails to work with your system, if it''s even possible.  It might
require
> more change than it is worth.
> 
> So at the risk of pissing off the fanboys: I think Rails is a great
> framework that pretty much forces me to be a more agile programmer... and
> that agility seems to be directly opposed to the sort of behemoth legacy
> system you are describing.  You might be able to do it, but you''d
be
> fighting Rails instead of playing to its strengths.
adding suport for a legacy schema, weird foreign key formats, etc, is pretty
simple. its just a trip to the API docs and a little typing. i''d still
recommend he try rails. i mean would you rather write your html in PHP than
markaby? or have a schema that cant be used with postgres since you use mysql
and didnt have ActiveRecord::Migration? what about pasting a bunch of javascript
when all you wanted to do was page.insert_element...

i found rails incredibly unopinionated. it doesnt care what web server, or db
engine or OS you use. theo nly thing it really enforces is that you use Ruby.
whats the harm in that? :)

On Sun, Jul 23, 2006 at 02:28:30AM +0200, Frank Burleigh
wrote:
> Frankly I''m losing tolerance for the MS "stack."  And
I''m intrigued by
> Rails.  But in my outfit I''m not only the web person, but also the
> application person and the DBA.  So when I read that Rails doesn''t
want
> to handle things like "compound keys" I blew right by those
claims,
> thinking, "no way."
> 
> But before I go deeper, I should ask: does Rails really prefer to stay 
> out of environments like mine where complex PKs and FKs, stored 
> procedures, and table names that aren''t always drawn from language
> (plural vs singular names) are deeply embedded in our infrastructure? 
> Do people like me in places like mine just stay out of Rails?
More or less.

Rails isn''t about helping you continue to destroy yourself with poor
practices, quietly hiding the insanity until it leaps out and consumes your
mind -- it''s about doing things *differently*.  Rails has strong
opinions on
what you''re doing, and it''s opinion isn''t a positive
one.

It sounds like you''re in a perfect position to repent your wicked ways,
though -- you don''t seem to have a large team of trogolodytes to
retrain.
You can just start working on new stuff The Rails Way and learn to love the
simplicity and ease of use.  Then when you''re convinced, you can start
teasing out some of the deeply embedded cruft and eventually reveal the
stark beauty that was hiding beneath the baroque complexity.

- Matt
(Remove tongue from cheek)

-- 
New Yankee Workshop isn''t a "how to" for home hobbyists,
it''s "Baywatch" for
powertool fetishists.
		-- Geoff Kinnel, ASR

Matthew Palmer wrote:
> On Sun, Jul 23, 2006 at 02:28:30AM +0200, Frank Burleigh wrote:
>> Do people like me in places like mine just stay out of Rails?
> More or less.
> 
Thanks "foobario," Carmen and Matt.  Those responses are variously
cool,
helpful and even entertaining.  Rails won''t like that we have addresses
in an Oracle table called address with primary key (id,type) and the job 
data in another table called job, or order line items in order_items 
keyed (order_id, item).  And the idea that much of our data gets in 
there with programs written in Delphi or C++ and that our users get 
their "lists" using 20 reports written in Crystal Reports probably
won''t
go down well either, eh? ;-)

Let me be clear I''m not seeking to malign Rails or the approach. 
They''re not selling infrastructures, so they have the freedom to make
me
worry about legacies, heterogeneity and all that.

So I summarize this way:

- Rails wants to do a lot of work for me.  Is there a place where I can 
read what operations it wants to do for me?  For example, sequenced 
indexes on db inserts are generated how?

- Rails prefers db keys not have "substance" in them (like people IDs 
and types).  I''m actually cool with that if I had a clean slate.  This 
would seem to make apps do more of the work.  Rails figures that''s 
good--provided it''s the only door into the data.

- Carmen figures it could be worth a go.  One thing I''ve learned over 
years of doing software: don''t fight the man to do your weirdo, edge 
case stuff unless you''ve learned a lot about the man''s insides
first.

- My first go doing simple tutorials a few weeks ago actually went quite 
well.  I was able to skip the mysql task list with Oracle tasks and get 
love.  But I had to worry: clearly mysql and postgres get attention from 
the community, but can I depend on the Oracle and Sybase parts being 
well cared-for?


-- 
Posted via http://www.ruby-forum.com/.

I''ve started work on Composite Primary Keys for Rails:

http://compositekeys.rubyforge.org

-- 
Posted via http://www.ruby-forum.com/.

Frank Burleigh wrote:
> Matthew Palmer wrote:
>   
>> On Sun, Jul 23, 2006 at 02:28:30AM +0200, Frank Burleigh wrote:
>>     
>>> Do people like me in places like mine just stay out of Rails?
>>>       
>> More or less.
>>
>>     
>
> Thanks "foobario," Carmen and Matt.  Those responses are
variously cool,
> helpful and even entertaining.  Rails won''t like that we have
addresses
> in an Oracle table called address with primary key (id,type) and the job 
> data in another table called job, or order line items in order_items 
> keyed (order_id, item).  And the idea that much of our data gets in 
> there with programs written in Delphi or C++ and that our users get 
> their "lists" using 20 reports written in Crystal Reports
probably won''t
> go down well either, eh? ;-)
>
> Let me be clear I''m not seeking to malign Rails or the approach. 
> They''re not selling infrastructures, so they have the freedom to
make me
> worry about legacies, heterogeneity and all that.
>
> So I summarize this way:
>
> - Rails wants to do a lot of work for me.  Is there a place where I can 
> read what operations it wants to do for me?  For example, sequenced 
> indexes on db inserts are generated how?
>
> - Rails prefers db keys not have "substance" in them (like people
IDs
> and types).  I''m actually cool with that if I had a clean slate. 
This
> would seem to make apps do more of the work.  Rails figures that''s
> good--provided it''s the only door into the data.
>
> - Carmen figures it could be worth a go.  One thing I''ve learned
over
> years of doing software: don''t fight the man to do your weirdo,
edge
> case stuff unless you''ve learned a lot about the man''s
insides first.
>
> - My first go doing simple tutorials a few weeks ago actually went quite 
> well.  I was able to skip the mysql task list with Oracle tasks and get 
> love.  But I had to worry: clearly mysql and postgres get attention from 
> the community, but can I depend on the Oracle and Sybase parts being 
> well cared-for?
>   
In mysql, I think that it just uses the mysql sequence by inserting 
without an ID, then getting the last id. It just uses the default DB 
autonumber method.

Something that is really nice about ruby, and ergo rails, is that you 
can override classes and methods in system classes very easily.
You don''t edit the system file, just redefine the class/method in your 
app. you don''t need to make a subclass to override things.


Jason