[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Ruby, Rails and now og

Andrew Ballantine

5/2/2005 9:45:00 AM

Hi,

I have recently "discovered" Ruby and have to say that it is a very refreshing change from procedural programming languages.

My query is:

"How does og (ObjectGraph) fit in with Rails or is it an alternative to Rails"

Hoping this is not too tedious a question.

Kind regards,

Andrew Ballantine.
15 Answers

Ilias Lazaridis

5/2/2005 10:58:00 AM

0

Andrew Ballantine wrote:
> Hi,
>
> I have recently "discovered" Ruby and have to say that it is a very
> refreshing change from procedural programming languages.
>
> My query is:
>
> "How does og (ObjectGraph) fit in with Rails or is it an alternative
> to Rails"

"og" is the persistency part of "Nitro" (a web-application framework)

it is a competitive product of "Rails" (which uses "ActiveRecord" as its
persistence library).

I've started an evaluation of "og":

http://laz.../case/persi...

If you are intrested, we can collaborate to produce the same for
ActiveRecord, thus gaining a deeper understanding due to an comparative
practical comparison.

please contact me via private email.

> Hoping this is not too tedious a question.
>
> Kind regards,
>
> Andrew Ballantine.

.

--
http://laz...

Bill Atkins

5/2/2005 11:53:00 AM

0

_Don't_ contact this guy "via private email." He's a nutcase. If you have
further questions, we'll be glad to help you out, but be warned that Ilias
is not a reputable source on anything.

On 5/2/05, Ilias Lazaridis <ilias@lazaridis.com> wrote:
>
> please contact me via private email.
>



--
Bill Atkins

Douglas Livingstone

5/2/2005 12:22:00 PM

0

On 5/2/05, Andrew Ballantine <andrew.ballantine@homecall.co.uk> wrote:

> "How does og (ObjectGraph) fit in with Rails or is it an alternative to Rails"
>
> Hoping this is not too tedious a question.
>

You just have to write your models using og instead of ActiveRecord.
You won't be able to take advantage of the support for ActiveRecord
built into Rails though.

Douglas



Ilias Lazaridis

5/2/2005 1:24:00 PM

0

Bill Atkins wrote:
> On 5/2/05, Ilias Lazaridis <ilias@lazaridis.com> wrote:
>
>>please contact me via private email.
>
> _Don't_ contact this guy "via private email." He's a nutcase. If you have

Please take care of your tenor.

> further questions, we'll be glad to help you out, but be warned that Ilias
> is not a reputable source on anything.

Please don't behabe like a fool.

The original poster is capable to verify the validity of the information
I gave him.

.

--
http://laz...

james_b

5/2/2005 1:38:00 PM

0

Andrew Ballantine wrote:
> Hi,
>
> I have recently "discovered" Ruby and have to say that it is a very refreshing change from procedural programming languages.
>
> My query is:
>
> "How does og (ObjectGraph) fit in with Rails or is it an alternative to Rails"


It is an alternative to Active Record (which is a part of Rails).

One difference between Og and AR is that Og handles the messy parts of
the persistence layer It writes the SQL for you (if the persistence
layer uses SQL; I believe there are, or will be, file system and
Kirbybase bindings).

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.


>
> Hoping this is not too tedious a question.

Not at all.

James

--

http://www.ru...
http://www.r...
http://catapult.rub...
http://orbjson.rub...
http://ooo4r.rub...
http://www.jame...


David Heinemeier Hansson

5/3/2005 9:50:00 PM

0

> 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.loudth... -- Broadcasting Brain
http://www.base... -- Online project management
http://www.rubyo... -- Web-application framework



Andrew Ballantine

5/3/2005 10:59:00 PM

0

David,

Thank you for a most comprehensive statement of the Rails point of view,
which incidentally matches my own experience of application development.

Kind regards,

Andrew Ballantine.
----- Original Message -----
From: "David Heinemeier Hansson" <david@loudthinking.com>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Tuesday, May 03, 2005 10:49 PM
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.loudth... -- Broadcasting Brain
> http://www.base... -- Online project management
> http://www.rubyo... -- 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
>
>



George Moschovitis

5/4/2005 4:06:00 PM

0

David,

You do not have to create the entire schema before starting your
application. In fact you don't care for the schema at all when
developing using Og. During the development phase you can alter your
classes and Og automatically adapts the schema for you. In this phase
you generally don't have any real data to care about.

Btw, Og can work just like AR if needed. Lets say you have a live Blog
application with the following class used to store Posts:

class Post
property :title, :body, String
belongs_to User
end

Lets say you want to add a new field in the database called
create_time. Just use you favourite SQL editor to alter the table and
then add the following line to your code:

class Post
...
property :create_time, Time
end

Extremely easy to do. Moreover, it is relatively easy to automate this
procces for most common cases. A future version of Og will
automatically adapt the schema for a live database.

While I am at it, let me point out some advantages of Og over AR:

- DRY: you can use Ruby's OOP features to build your tables using
inheritance and mixins.

- DRY: you only define your relations (associations) once. In AR you
define the relations in SQL (foreign keys etc) and in Ruby code
(associations)

- uses standard Ruby objects and not beutified hashes.

- you can switch the backend RDBMS by changing one line of code.

- complex patterns like nested_sets/nested_elements can be fully
encapsulated (In AR you have to know the pattern and manually add
columns to the schema)

- You have access to full property/relation metadata for all backends.

- The schema is generated automatically for you.

- generates more optimized code for the managed objects.

I am also working on 'Og-Reloaded'. A brand new implementation of the
low level code and carefully designed changes to the API to support
many many new features.

Stay tuned for an *impressive* new release!

regards,
George.

Paul Hanchett

5/4/2005 4:20:00 PM

0

Oooo George--- Now you've got me excited! ;-)

George Moschovitis wrote:
> David,
>
> You do not have to create the entire schema before starting your
> application. In fact you don't care for the schema at all when
> developing using Og. During the development phase you can alter your
> classes and Og automatically adapts the schema for you. In this phase
> you generally don't have any real data to care about.
>
> Btw, Og can work just like AR if needed. Lets say you have a live Blog
> application with the following class used to store Posts:
>
> class Post
> property :title, :body, String
> belongs_to User
> end
>
> Lets say you want to add a new field in the database called
> create_time. Just use you favourite SQL editor to alter the table and
> then add the following line to your code:
>
> class Post
> ...
> property :create_time, Time
> end
>
> Extremely easy to do. Moreover, it is relatively easy to automate this
> procces for most common cases. A future version of Og will
> automatically adapt the schema for a live database.
>
> While I am at it, let me point out some advantages of Og over AR:
>
> - DRY: you can use Ruby's OOP features to build your tables using
> inheritance and mixins.
>
> - DRY: you only define your relations (associations) once. In AR you
> define the relations in SQL (foreign keys etc) and in Ruby code
> (associations)
>
> - uses standard Ruby objects and not beutified hashes.
>
> - you can switch the backend RDBMS by changing one line of code.
>
> - complex patterns like nested_sets/nested_elements can be fully
> encapsulated (In AR you have to know the pattern and manually add
> columns to the schema)
>
> - You have access to full property/relation metadata for all backends.
>
> - The schema is generated automatically for you.
>
> - generates more optimized code for the managed objects.
>
> I am also working on 'Og-Reloaded'. A brand new implementation of the
> low level code and carefully designed changes to the API to support
> many many new features.
>
> Stay tuned for an *impressive* new release!
>
> regards,
> George.
>

David Heinemeier Hansson

5/4/2005 9:13:00 PM

0

> During the development phase you can alter your
> classes and Og automatically adapts the schema for you. In this phase
> you generally don't have any real data to care about.

That sure depends on the application and your willingness to eat your
own dog food. Basecamp, Ta-da List, and Backpack were all managing
our real data shortly after the first SVN check-in. Hence, the window
of not caring about loss of data was essentially nil.

From the point where you have data that matters, the object-to-SQL
(OTS) approach is merely yet another step required to evolving your
domain model.

In Rails, adding the field address to the model Person is one step
during development:

1) Adding the field in the db (how fast that is in practice can be
seen nicely in the initial Rails window that tabs back and forth
between editor and DB GUI in seconds).

The same change in an OTS system is a repeating two-step approach
where you first inform the database of the change, then say the same
to the domain model.

> - uses standard Ruby objects and not beutified hashes.

Heh. Who needs to beautify a hash? She's looking mighty good to me.
And if she needs more sassy, I'm sure _why and his foxes can do a
much better job than a framework abbreviated as AR(GH).

Seriously now.

> - you can switch the backend RDBMS by changing one line of code.

That is indeed an alluring prospect. To be able to generate SQL for
multiple flavors from a single definition. Some applications truly
need that. Which is why Active Record is getting an optional
definition style just for this purpose. I could definitely see
Instiki on Active Record use this to good effect.

It's however not something that matters for a large class of
applications, like the ASP-based ones from 37signals. So burdening
all with repetition needed by few didn't seem like a trade-off that
made sense for Active Record. (Somewhat related to that is the Jeremy
Zadwodny's argument that "Database Abstraction Layers Must Die!" --
http://jeremy.zawodny.com/blog/archives/0... -- especially in
the context of using find_by_sql, execute, and the option that SQL is
not evil).


Now what's much more interesting than OTS or STO is how to deal with
an evolving database scheme where you can't throw out the data on
every change. Martin Fowler had a good discussion on that in his
Evolutionary Database Design[1] article.

Active Record is tackling this problem through a new system called
Migrations, which basically turns the database -- data and schema --
into a revision controlled system that can be evolved just as easily
as code (integrated into the Rails workflow as well).

When you're using migrations, the complete schema is a lot less
interesting than the diffs. With migrations, it's easy to allow
multiple developers to be at separate stages on the evolving
database, like Fowler's article describes. At the same time, it's the
system you can use in your deployment chain.

Which is of course exactly what we're doing for Backpack now. Jamis,
the designers, and I each have our own database instances and are
happily keeping in sync through Migrations. And when we decide to do
"rake deploy", the live version keeps up.

[1] http://www.martinfowler.com/articles/...
--
David Heinemeier Hansson
http://www.loudth... -- Broadcasting Brain
http://www.base... -- Online project management
http://www.rubyo... -- Web-application framework