Rails - Jan 2006 - Plans to intigrate ObjectGraph in to Rails

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:
http://www.rubygarden.org/index.cgi/Libraries/og_tutorial.rdoc

Example code:

[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
[/code]

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

Peter Piper 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...

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

2006/1/16, Peter Piper <pete@example.com>:
> 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

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.


On Jan 16, 2006, at 18:45 , Peter Piper wrote:
> 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:
> http://www.rubygarden.org/index.cgi/Libraries/og_tutorial.rdoc
>
> Example code:
>
> [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
> [/code]
>
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

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. :-)

b



Peter Piper wrote:
> 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:
> http://www.rubygarden.org/index.cgi/Libraries/og_tutorial.rdoc
> 
> Example code:
> 
> [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
> [/code]
>

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

Ben Munat 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.
-- 
Posted via http://www.ruby-forum.com/.

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
http://www.artima.com/rubycs/ - 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

James Britt wrote:
> mikkel wrote:
> 
>> there is no problems using another ORM package in a rails project...
>>
> 
> What other ORMs have you used?
> 
> 
> James
> 
> 
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

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 :)

Peter Piper.



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

2006/1/17, Peter Piper <pete@example.com>:
> 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

> > 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 Hansson
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

Douglas Livingstone wrote:
> 2006/1/17, Peter Piper <pete@example.com>:
>> 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.






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