Rails - Mar 2005 - Some Thoughts on Keeping the Table Schema in the AR Model Code

In general, when I''m building an app with RoR, I usually keep my
database schema in a file in the db directory called schema.sql, then
I edit this file as needed. I usually also create a Rake task to
(re)install the schema into the actual database. The only thing that
bugs me is that, since AR model classes don''t (necessarily) have
information in the class definition that represents all of the db
columns, I often have to keep this schema file open just to reference
the names/types of the columns while I''m coding.

It''s not a big deal, but it would be nice if this information could
somehow be in the model class definition itself. Granted, I could
simply list the information in the comments for the class, but this
would be a pain-in-the-butt as well as a violation of DRY.

What if the model classes new how to create the tables for me? I don''t
mean one of those systems where the table is created based on the
attributes of the class -- I''m thinking of just having a method on the
class that contains the actual SQL (just like you''d put in that schema
file) to create the table. Then the information would be right there
in the class definition. A task could then be added to the Rakefile
that would ask each model class for its schema definition and then
create the tables for you. The task could even be set up to allow you
to specify a single model class to create the table for. I.E:
  %> rake create_tables
or:
  %> rake create_table SomeModelClass

If you wanted the app to support multiple database adapters, you could
have a method on the class named for each type of adapter, and then
the master install method could choose the correct one based on the
adapter specified for the environment you run the command under.

This solution has the advantage of being completely optional (so it
wouldn''t affect older apps or people who don''t want to or
can''t keep
the schema definition in the AR classes), and it would keep the
information about the table schema as close as possible to the code
that actually uses that table.

Thoughts?
-- 
Regards,
John Wilger

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don''t know," Alice answered.
"Then," said the cat, "it doesn''t matter."
- Lewis Carrol, Alice in Wonderland

This has been discussed before and I believe they rails team is going to 
implement this.

I also like the idea alot, running into the exact same problems you 
described, always needing to refer back to the schema for names of 
attributes

John Wilger wrote:
>In general, when I''m building an app with RoR, I usually keep my
>database schema in a file in the db directory called schema.sql, then
>I edit this file as needed. I usually also create a Rake task to
>(re)install the schema into the actual database. The only thing that
>bugs me is that, since AR model classes don''t (necessarily) have
>information in the class definition that represents all of the db
>columns, I often have to keep this schema file open just to reference
>the names/types of the columns while I''m coding.
>
>It''s not a big deal, but it would be nice if this information could
>somehow be in the model class definition itself. Granted, I could
>simply list the information in the comments for the class, but this
>would be a pain-in-the-butt as well as a violation of DRY.
>
>What if the model classes new how to create the tables for me? I
don''t
>mean one of those systems where the table is created based on the
>attributes of the class -- I''m thinking of just having a method on
the
>class that contains the actual SQL (just like you''d put in that
schema
>file) to create the table. Then the information would be right there
>in the class definition. A task could then be added to the Rakefile
>that would ask each model class for its schema definition and then
>create the tables for you. The task could even be set up to allow you
>to specify a single model class to create the table for. I.E:
>  %> rake create_tables
>or:
>  %> rake create_table SomeModelClass
>
>If you wanted the app to support multiple database adapters, you could
>have a method on the class named for each type of adapter, and then
>the master install method could choose the correct one based on the
>adapter specified for the environment you run the command under.
>
>This solution has the advantage of being completely optional (so it
>wouldn''t affect older apps or people who don''t want to or
can''t keep
>the schema definition in the AR classes), and it would keep the
>information about the table schema as close as possible to the code
>that actually uses that table.
>
>Thoughts?
>  
>

On Fri, 25 Mar 2005 10:15:13 -0800, Francisco Hernandez
<lagcisco-b7MHZcQsHeJWk0Htik3J/w@public.gmane.org>
wrote:
> This has been discussed before and I believe they rails team is going to
> implement this.
Can anyone here speak as to the status of this (if it is indeed
planned to be implemented in the framework)? If no one is actively
working on it, I''m more than happy to volunteer.
-- 
Regards,
John Wilger

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don''t know," Alice answered.
"Then," said the cat, "it doesn''t matter."
- Lewis Carrol, Alice in Wonderland

> I also like the idea alot, running into the exact same problems you
> described, always needing to refer back to the schema for names of
> attributes
So instead of looking at the DB schema, you''ll be looking at the model
source for the names of attributes?  How is this better?

Personally I''m for it if I can specify the columns in the model and
skip that extra SHOW FIELDS query.

-- 
rick
http://techno-weenie.net

On Fri, 25 Mar 2005 12:50:01 -0600, Rick Olson
<technoweenie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Personally I''m for it if I can specify the columns in the model
and
> skip that extra SHOW FIELDS query.
Then you may want to look at a different ORM layer such as Og. You
should be able to use the ActionPack and other parts of Rails with
_any_ well-designed ORM layer.

-- 
Regards,
John Wilger

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don''t know," Alice answered.
"Then," said the cat, "it doesn''t matter."
- Lewis Carrol, Alice in Wonderland

It feels a bit more natural for me to look at the model for attributes 
instead of the db schema if I''m doing some work with the model objects,
but I do understand your point of view, I''d still need to lookup that 
information somewhere regardless

Rick Olson wrote:
>>I also like the idea alot, running into the exact same problems you
>>described, always needing to refer back to the schema for names of
>>attributes
> 
> 
> So instead of looking at the DB schema, you''ll be looking at the
model
> source for the names of attributes?  How is this better?
> 
> Personally I''m for it if I can specify the columns in the model
and
> skip that extra SHOW FIELDS query.
>

Hello John,

Perhaps you would like to help me with  the necessary changes to make
Og more compatible with Rails. Og implements what you propose with the
added bonus of an API similar to AR.

Have a look at the tutorial (http://www.rubygarden.com) and grab the
latest (not officially released) version, og-0.13.1.gem, from
http://nitro.rubyforge.org.

regards,
George.


On Fri, 25 Mar 2005 13:34:13 -0500, John Wilger
<johnwilger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Fri, 25 Mar 2005 10:15:13 -0800, Francisco Hernandez
> <lagcisco-b7MHZcQsHeJWk0Htik3J/w@public.gmane.org> wrote:
> > This has been discussed before and I believe they rails team is going
to
> > implement this.
> 
> Can anyone here speak as to the status of this (if it is indeed
> planned to be implemented in the framework)? If no one is actively
> working on it, I''m more than happy to volunteer.
> --
> Regards,
> John Wilger
> 
> -----------
> Alice came to a fork in the road. "Which road do I take?" she
asked.
> "Where do you want to go?" responded the Cheshire cat.
> "I don''t know," Alice answered.
> "Then," said the cat, "it doesn''t matter."
> - Lewis Carrol, Alice in Wonderland
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 

-- 
http://nitro.rubyforge.org
http://www.joy.gr

> Can anyone here speak as to the status of this (if it is indeed
> planned to be implemented in the framework)? If no one is actively
> working on it, I''m more than happy to volunteer.
The work is somewhat half-finished. I would indeed like help on  
wrapping it up. The story is that I''m working on an a new feature  
called Migrations, which will make it possible to work in an agile  
manner with database schema migrations. In order to do that I need an  
abstraction for creating tables and columns.

This abstraction is well suited to be adapted for fields-in-model too.  
See:

http://one.textdrive.com/pipermail/rails/2005-February/003646.html

Follow the trail from active_schema_mysql.rb:
http://dev.rubyonrails.com/file/trunk/activerecord/test/ 
active_schema_mysql.rb
--
David Heinemeier Hansson,
http://www.basecamphq.com/   -- Web-based Project Management
http://www.rubyonrails.org/  -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

David,

have you looked at iBatis SQLMaps? - 
http://www.ibatis.com/common/sqlmaps.html

One of the guiding principles (pitched as a feature over Hibernate) is 
the fact that the SQL is specified in a way that makes DBAs happier 
because they control more.

I like it because the SQL is visible and in one place (ok, you can split 
across multiple config files for modularity but the principle is there). 
  They''ve also spent some time working on the problem of N+1 selects 
building an object graph too (although IMHO they could go further).

The config format is (of course) XML but I''m sure expressing it in ruby
could end up being quite sweet.

Just a heads-up...

Trevor

David Heinemeier Hansson wrote:
>> Can anyone here speak as to the status of this (if it is indeed
>> planned to be implemented in the framework)? If no one is actively
>> working on it, I''m more than happy to volunteer.
> 
> 
> The work is somewhat half-finished. I would indeed like help on  
> wrapping it up. The story is that I''m working on an a new feature
> called Migrations, which will make it possible to work in an agile  
> manner with database schema migrations. In order to do that I need an  
> abstraction for creating tables and columns.
> 
> This abstraction is well suited to be adapted for fields-in-model too.  
> See:
> 
> http://one.textdrive.com/pipermail/rails/2005-February/003646.html
> 
> Follow the trail from active_schema_mysql.rb:
> http://dev.rubyonrails.com/file/trunk/activerecord/test/ 
> active_schema_mysql.rb
> -- 
> David Heinemeier Hansson,
> http://www.basecamphq.com/   -- Web-based Project Management
> http://www.rubyonrails.org/  -- Web-application framework for Ruby
> http://www.loudthinking.com/ -- Broadcasting Brain
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails