Forum: Ruby on Rails Database independent representation of schema

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
F8fd54072606eaf5603484e756672034?d=identicon&s=25 lists (Guest)
on 2005-12-04 03:11
(Received via mailing list)
Guys,

Been away from Rails for awhile but am finally diving back in.

I know there had been some discussion of (and I have been logging for)
adding definition of a database schema in a file outside of the
database,
a la Hibernate.

In other words, in Hibernate you define your object relationships in
external xml files and you can then use the packaged tools (hbm2ddl) to
generate DDL for the target database.

Why is this nice? First, you go about designing your application truly
thinking about the objects, and not the tables, from the get go (to a
certain extent). But secondly, and most important, I don't have to
rewrite
the DDL each time I switch from say, Hsqldb (for demos), to PostgreSQL
(production).

Has there been any movement on things in this regard in Rails?

Thanks for the info.

John
67b6389be42524fbd776e44fd35c3d7e?d=identicon&s=25 peter.j.donald (Guest)
on 2005-12-04 03:43
(Received via mailing list)
Hi,

You may want to have a look at migrations that allow you to define it
in a database agnostic way for postgres and mysql.

http://wiki.rubyonrails.com/rails/pages/Understand...
http://api.rubyonrails.com/classes/ActiveRecord/Mi...

If you need foreign key enforcement then you will need to look at
"Foreign Key Schema Dumper Support" on
http://wiki.rubyonrails.com/rails/pages/Plugins

--
HTHs,

Peter Donald
821395fe70906c8290df7f18ac4ac6cf?d=identicon&s=25 technoweenie (Guest)
on 2005-12-04 04:40
(Received via mailing list)
On 12/3/05, John Wells <lists@sourceillustrated.com> wrote:
> generate DDL for the target database.
>
> Why is this nice? First, you go about designing your application truly
> thinking about the objects, and not the tables, from the get go (to a
> certain extent). But secondly, and most important, I don't have to rewrite
> the DDL each time I switch from say, Hsqldb (for demos), to PostgreSQL
> (production).
>
> Has there been any movement on things in this regard in Rails?

You're looking for migrations and schemas.  You still define your
relationships and all that in the code.  Schemas and migrations use
the database agnostic methods of the Connection Adapter for the DDL
queries.  It makes it a snap to develop and test in different
databases, support multiple ones, and make iterative changes.

Kevin wrote a great article on Migrations themselves.  The actual
methods are the same for schemas.  Just type rake db_schema_dump to
see the autogenerated schema for your current database.

http://glu.ttono.us/articles/2005/10/27/the-joy-of...

--
rick
http://techno-weenie.net
87f401c89948d2ed7de4b530fbf0a35c?d=identicon&s=25 jb (Guest)
on 2005-12-04 17:56
(Received via mailing list)
Peter Donald said:
> You may want to have a look at migrations that allow you to define it
> in a database agnostic way for postgres and mysql.

Thanks Peter. This is definitely a step in the right direction. It seems
somewhat green in terms of features (not yet supporting NOT NULL, etc),
but definitely workable. Too bad it doesn't support sqlite...we use it
for
demo for our rails app while the production version runs on PostgreSQL.

Thanks for the pointer!

John
Eea3feaacbe44706164289d068d94828?d=identicon&s=25 petermichaux (Guest)
on 2005-12-04 18:46
(Received via mailing list)
I don't know much about migrations yet but the following two points made
me
wonder.

On 12/4/05, John Wells wrote:
>
>  It seems somewhat green in terms of features (not yet supporting NOT
> NULL, etc)


what about  ":null => false"?

Too bad it doesn't support sqlite


>From http://glu.ttono.us/articles/2005/10/27/the-joy-of...

"Migrations are database agnostic. What this means is that you can write
your description of the database in ruby -once- and have it easily
translate
to MySQL, PostgreSQL or SQLite out of the box."

-Peter
Eea3feaacbe44706164289d068d94828?d=identicon&s=25 petermichaux (Guest)
on 2005-12-04 19:39
(Received via mailing list)
Currently I use raw SQL for DDL because I can also populate/seed my
database
in the same file. It is nice because my INSERT statements can be written
directly below my CREATE TABLE statements.

If I switch to using schema.rb to define my database what is the best
way to
seed it?. I'd like to type one command to both define and seed the
database.

Thanks,
Peter
280b41a88665fd8c699e83a9a25ef949?d=identicon&s=25 steve (Guest)
on 2005-12-04 22:42
(Received via mailing list)
On Dec 4, 2005, at 10:35 AM, Peter Michaux wrote:

> Currently I use raw SQL for DDL because I can also populate/seed my
> database in the same file. It is nice because my INSERT statements
> can be written directly below my CREATE TABLE statements.
>
> If I switch to using schema.rb to define my database what is the
> best way to seed it?. I'd like to type one command to both define
> and seed the database.

See the second example in the [ActiveRecord::Migration documentation]
[1].

--Steve

[1]: http://api.rubyonrails.com/classes/ActiveRecord/Mi...
67b6389be42524fbd776e44fd35c3d7e?d=identicon&s=25 peter.j.donald (Guest)
on 2005-12-04 23:07
(Received via mailing list)
Hi,

On 12/5/05, Peter Michaux <petermichaux@gmail.com> wrote:
> Currently I use raw SQL for DDL because I can also populate/seed my database
> in the same file. It is nice because my INSERT statements can be written
> directly below my CREATE TABLE statements.
>
>  If I switch to using schema.rb to define my database what is the best way
> to seed it?. I'd like to type one command to both define and seed the
> database.

You can populate your database using the model object directly. ie

MyFoo.create( :field1 => 'blah', :field2 => 2 )

or

foo = MyFoo.new
foo.field1 = 'blah'
foo.field2 = 2
foo.save

--
Cheers,

Peter Donald
This topic is locked and can not be replied to.