Plans to intigrate ObjectGraph in to Rails

Rails
1

Are there any plans to move the schema definition from migrations to the
model, where it should be?

Like og does, which I think is used by the ruby Nitro framework…
ObjectGraph:

Example code:

class Post
    property :title, String, :sql => 'VARCHAR2(32) NOT NULL'
    property :body, String
    property :author, String
    property :create_time, Time
    property :hits, Fixnum, :sql_index => true

    has_many :comments, Comment
end
2

Peter P. wrote:

Are there any plans to move the schema definition from migrations to the
model, where it should be?

says who???

dont hold your breath…I dont think that would happen…

3

2006/1/16, Peter P. [email protected]:

Are there any plans to move the schema definition from migrations to the
model, where it should be?

The schema definition is in the application’s database, no need to use
migrations to have a schema.

Douglas

4

I like the control over the database layout with the “:sql” extension
to further refine data types.

If the SQL to create the database objects could also be generated to
run through psql or sqlplus, that would be a bonus. Including alter
statements to handle migrations, and changes to the datbase.

Would also be nice to have to indicate what tablespace, storage
parameters, etc that a table or index would be created in. This
would be specific to Oracle or PostgreSQL.

Any reason the extensions couldn’t just be passed to the SQL
generator which creates the database objects in the first place?

I think taking some of the pieces from OG would be nice, and having
all the metadata in the class definition is a bonus.

Cheers,
Mike

–
Mobile: +81-80-3202-2599
Office: +81-3-3395-6055

“You can figure out how to get it off. It’s on the Internet. I
looked it up.”
Martha Stewart - re: her proximity restraint.

5

there is no problems using another ORM package in a rails project…

Ben M. wrote:

For that matter, I’m still very new to rails, but I wonder if it would
be that much work
to get ActionPack talking to Og? Shouldn’t be, since the controllers and
views are clients
of the model. The main chunk of work would probably be writing new
generators. You would
write up the definitions for your model classes and then have the
generators create
controllers and views. Talking to the db is all Og.

6

mikkel wrote:

there is no problems using another ORM package in a rails project…

What other ORMs have you used?

James

–

http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

7

I’d love to see the option of a “domain-first” ORM like Og in rails…
but I wouldn’t wait
for the committers to agree with you. Throw a project together, make an
announcement on
the list and see if you can get enough people to help. Maybe the Og devs
would be interested.

For that matter, I’m still very new to rails, but I wonder if it would
be that much work
to get ActionPack talking to Og? Shouldn’t be, since the controllers and
views are clients
of the model. The main chunk of work would probably be writing new
generators. You would
write up the definitions for your model classes and then have the
generators create
controllers and views. Talking to the db is all Og.

It would also be nice if, with a single configuration, you could have Og
write to flat
files, yaml, or xml. I haven’t looked too closely at Og, so maybe it
already does that…

I’ve seen others talking about this idea. Someone just needs to stop
talking about it and
start doing it. If we’re still just talking about it in a few months
(after I’ve had a
chance to learn a bit more about Ruby and Rails), I’ll do it. Hopefully
someone will beat
me to it. :slight_smile:

b

8

James B. wrote:

Yeah… and I don’t know if you could really call it a “rails” app at
that point… ActiveRecord is so central to rails…

b

9

2006/1/17, Peter P. [email protected]:

The model should not have to be dependant
on a exisitng table, it should be able to create its own - but i guess
thats nit picking.

If there is already a table, but it has a diffferent schema from the
model… you want the model to simply drop the the old table??

Douglas

10

Well the model describes the data so it seems natural to me to have the
schema definition in the model. Of course this is my opinion…

Having the schema in the model also allows instant visualisation of what
fields that model/table has.

I really liked Migrations when I first used it - its great for team
collab as well - but I think the schema should be in the model.

The trouble with og is you cant rollback like with Migrations, unless…
you use version control you could rollback the model.rb file and get the
old schema if required.

The model represents the data. The model could create the table
(automatic setup program for install of an application a bonus), plus I
think it is more Object Orinentated to do this. Self contained classes
of independant functionality. The model should not have to be dependant
on a exisitng table, it should be able to create its own - but i guess
thats nit picking.

Just some thoughts, I think I will try og instead of ActiveRecord, you
would surly still call it a Rails app… As long as dispaches is being
used I guess its a rails app :slight_smile:

Peter P…

11

Douglas L. wrote:

2006/1/17, Peter P. [email protected]:

The model should not have to be dependant
on a exisitng table, it should be able to create its own - but i guess
thats nit picking.

If there is already a table, but it has a diffferent schema from the
model… you want the model to simply drop the the old table??

Douglas

Yes I see the point… but there would be no need to drop the table,
only change what is different, just as migrations would. It partly
depends on if you are talking about development or production, and if
production I guess retaining exisitng data is important, and to do this
yes you get better flexability in migrations because you can add
migration code. Og I guess has static schema, not transisional.

I think my point partly comes from retaining pure OO programming… the
model is the data, all encompassing. But I think none comprise is more
practical?

Pete.

12

The model should not have to be dependent
on a existing table, it should be able to create its own - but i guess
thats nit picking.

If there is already a table, but it has a different schema from the
model… you want the model to simply drop the the old table??

This is the crux of the problem. Schema-in-model sounds nice until the
first time you have to change it in an application where you care
about the data. Suddenly schema-in-model is liability. One that forces
you to get wet and most often manage the entire migration without the
help of the framework.

I summarized all the reasons for why schema-in-model is unattractive
to developers that care about keeping their schema as agile as their
code and have real data to worry about in
http://media.rubyonrails.org/video/migrations.mov.

Re different model backends: I’ve had Rails applications that used
both Madeleine and flat files. Others have interfaced with ActiveLDAP.
Active Record is not a necessity for a Rails application. But yes, if
you need a relational backend, it works better than the alternatives
because we based the conventions around it. So smooth, yes, necessary,
no.

David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework