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.
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://lazaridis.com/case/persist/og.html
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.
..
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
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.
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
_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
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
Bill Atkins 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.
..
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.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
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.
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
endLets 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
endExtremely 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.
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!" -- Database Abstraction Layers Must Die! (by Jeremy Zawodny) -- 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] Evolutionary Database Design
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com -- Online project management
http://www.rubyonrails.com -- Web-application framework
Hashes certainly are women. Primarily because they don't respect order.
marcel
On Thu, May 05, 2005 at 06:13:03AM +0900, David Heinemeier Hansson wrote:
>- uses standard Ruby objects and not beutified hashes.
Heh. Who needs to beautify a hash? She's looking mighty good to me.
--
Marcel Molina Jr. <marcel@vernix.org>
Hello David,
Basecamp, Ta-da List, and Backpack were all managing
our real data shortly after the first SVN check-in.
naah, you are exagerating here... You don't put real data on a project
that you created 5 mins ago
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.
Not really, the extra step takes half a minute max. And you don't
change your schema regularily after you have inserted some real data.
BTW, let me give you a real world example (your little video is not a
real world case):
Lets say you have a table with a column named body, and you want to
rename this to description. Issuing the ALTER TABLE command takes
hmm... 1 minute (I am always scared issuing ALTER TABLE on live data
:-)) Adding the 1 line for Og takes 0.5 minute. Changing all your code
to use the new name can take half an hour, ie an order of magnitude
compared to the extra step needed in Og. So there is no problem in
practice.
But to keep you happy, I 'll have Og automatically issue the ALTER
statement for most common cases. This will make the process even easier
than AR: just do an SVN update on the live server and restart. No need
to play with the live database and maybe make a dangerous mistake.
Some applications truly need that.
Have a look at Typo's db directory, talk about DRY
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
...
[1] Evolutionary Database Design
Thanks for the interesting discussion. I 'll have a look at that
article.
best regards,
George
George Moschovitis wrote:
Hello David,
Basecamp, Ta-da List, and Backpack were all managing
our real data shortly after the first SVN check-in.naah, you are exagerating here... You don't put real data on a project
that you created 5 mins ago
you cannot know every use-case of every potential users.
this is "developers arrogance".
The same change in an OTS system is a repeating two-step approach
[...]
what you write further in your message is unbelievable.
You should really focus to setup the _project_, before going in comparision with mature products.
-
Note to readers:
The core diffence between Rails/ActiveRecord and Nitro/Og is:
-
* Rails is an active product with an active user community
* The project-organization looks efficient and code-level contributions are engouraged:
-
Nitro/Og is currently "vapoware".
* no active user base
* the development goes without any planning
* simple requests are not served.
* developers _code_ level contributions and not engouraged
* no feedback from the only developer G. Moschovitis
* There's _no_ public source repository (yes you read correct)
* following development and synchronize own efforts is inpossible
* the nitro/og development lasts years, without any stable product.
* it does not look that this will change
I try since 2 months to apply a _simple_ evaluation case:
http://lazaridis.com/case/persist/og.html
no success
-
As I'm intrested in Object Centric Development, Rails is not relevant for me (DataStore Centric).
-
[currently I'm modifying the 0.16 version to provide automated column addition with sqlite3]
http://thread.gmane.org/gmane.comp.lang.ruby.nitro.general/204
some more threads:
http://news.gmane.org/gmane.comp.lang.ruby.nitro.general
..
Ohh well 
George.
George Moschovitis wrote:
Ohh well
smilies as the last response.
you are writing a persistency-layer, not a painting programm.
get professional.
George.
..