Actually no. I don't have an alternative ORM to hawk. And I should
have said in my earlier post that I've never used Rails, or Og. So I
don't really know what I'm talking about! From everything I've read and
heard about it, Rails sounds great. I don't know anything about Og.
But on the surface, being able to play around with a domain model
without worrying about SQL or the db at all, then hitting a button on
the ORM tool that says 'generate (or alter) schema', does sound
appealing. (And maybe you can do that with Rails/ActiveRecord?)
Steve
ยทยทยท
-----Original Message-----
From: Andrew Ballantine [mailto:andrew.ballantine@homecall.co.uk]
Sent: Tuesday, May 03, 2005 6:08 PM
To: ruby-talk ML
Subject: Re: Ruby, Rails and now og
Steve,
Are you hinting at an alternative to rails?
Kind regards,
Andrew Ballantine.
----- Original Message -----
From: "Molitor, Stephen L" <Stephen.L.Molitor@erac.com>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Tuesday, May 03, 2005 11:50 PM
Subject: Re: Ruby, Rails and now og
You write a few methods, add a few columns, write some more methods,
add another table, and on we go.
And if you change your mind, you have to remove a few methods, flip over
to the db, remove a few columns, flip back to ruby, remove a class, flip
back to the db, remove the table....no?
Steve
-----Original Message-----
From: David Heinemeier Hansson [mailto:david@loudthinking.com]
Sent: Tuesday, May 03, 2005 4:50 PM
To: ruby-talk ML
Subject: Re: Ruby, Rails and now og
What I like about this is I can write and evolve my application with a
focus on objects and behavior, without thinking of what database, if
any, I might be using, or what tables, if any, I might need to create.
As I go along, I can easily add persistence to objects by adding a few
lines of code to the class def.
It helps avoid a lot of big upfront design.
Heh. This would of course only be true be under the assumption that you
had to create your entire schema before starting on the object- oriented
part of the domain model. Which is false, of course.
Active Record is imminently suited and created with special attention
for evolving designs. The Rails way of designing your schema is column
by column as they're needed by the domain model. I'll often times start
a new domain model with linked to a table with just a single column. A
person object birthed with just a name, for example.
The great thing about working column by column is that the "conversion"
from object to database is transparent and happens all the time. You
write a few methods, add a few columns, write some more methods, add
another table, and on we go. There's no build phase where the framework
generates SQL, which then has to be loaded against your database, and
which will destroy the test data you've been working with.
Object-to-SQL conversions have their place. One of them is the
capability of generating multiple flavors of SQL from a single
definition. Preventing big upfront design is something you do by
choosing to. It's unrelated to the choice between Object-to-SQL or
SQL-to-object.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.rubyonrails.com -- Web-application framework
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.2 - Release Date: 02/05/2005