Hi,
I’m looking at developing a reasonably complex web application, where
most of the complexity actually lays in the database and the queries
I need run on it. Some “classes” or models need to consist of an
assembly of several tables. It would be trivial enough for me to code
these queries in SQL, but as far as I understand Rails is trying to
hide the database as much from me as possible. I have only a general
idea of how Rails works but want to give it a try for this project,
mainly because I want to get some experience with it. I’m just
wondering how fit it is for the task. Is it a simple matter of
building the models correctly or will I need to do more to bend Rails
to do my bidding? ;o)
Any ideas welcome.
Cheers,
Dav
Hi David
AcctiveScaffold plugin may just be the solution for you 
David Zentgraf wrote:
wondering how fit it is for the task. Is it a simple matter of
building the models correctly or will I need to do more to bend Rails
to do my bidding? ;o)
Any ideas welcome.
Cheers,
Dav
I assume that it is an existing database, or otherwise you could just
create the tables to match your models. The simplest option otherwise
is to create a view for each model by selecting the data you need. If
you follow Rails’ naming conventions with the views in your database
and your attributes in the models, Rails will treat the view exactly
as it would a table, and the database will take care of the rest.
(Note if you’re using Oracle, you will need to add triggers to update
the underlying tables, and PostgreSQL requires some additional lines.)
Cheers,
Matt
David Zentgraf wrote:
wondering how fit it is for the task. Is it a simple matter of
building the models correctly or will I need to do more to bend Rails
to do my bidding? ;o)
Without specific examples it’s impossible for us to tell you how much
work it might be to get Rails to do what you would like it to do.
–
Michael W.
On 4. Oct 2007, at 11:50, fotn wrote:
I assume that it is an existing database, or otherwise you could just
create the tables to match your models. The simplest option otherwise
is to create a view for each model by selecting the data you need. If
you follow Rails’ naming conventions with the views in your database
and your attributes in the models, Rails will treat the view exactly
as it would a table, and the database will take care of the rest.
(Note if you’re using Oracle, you will need to add triggers to update
the underlying tables, and PostgreSQL requires some additional lines.)
Actually no, I’m still completely in the planning stages of the
project and am building my tables the way I’d usually do it using PHP/
SQL for example. I am looking at postgres as my database, mostly
because it includes CHECK() functions.
Am I tackling this the wrong way for using Rails?
Example:
I’ll have three or four different types of “objects”, which are all
very related and just variations of the same idea. In my database I
have table A, B and C. A contains information common to all
“objects”, whereas B and C contain various extra information in a
many-to-one relationship to A. Depending on whether there are entries
in B or C referencing the object in A, the object can be considered
to be of a different type and have different uses within the
application.
It’s rather trivial to do SQL queries on that like SELECT * FROM a
WHERE id IN (SELECT a_id FROM b WHERE [condition])… etc.
How would I go about this in rails? Can I abstract these queries to
such a degree in views?
Cheers.
It almost sounds like you are after either polymorphism or single-
table inheritance. An example of polymorphism is on the Rails wiki:
http://wiki.rubyonrails.org/rails/pages/
UnderstandingPolymorphicAssociations
Single-table inheritance is a slightly simpler method wherein all
data resides in a (coincidentally) single table but is viewed
differently depending on the object type:
http://wiki.rubyonrails.org/rails/pages/SingleTableInheritance
Regarding creating the tables with SQL statements. Many, if not most
Rails developers are using migrations. That way you can have a
versionable schema that is independent of the backbone.
HTH
On 4. Oct 2007, at 11:45, CCH wrote:
Hi David
AcctiveScaffold plugin may just be the solution for you
I’ll have a look whether that can do anything for me, thanks.
On 4. Oct 2007, at 12:53, Michael W. wrote:
Active Record supports both Single Table Inheritance where you
basically
mash all the information into a single table and Polymorphic
Associations where the extra information is kept in separate tables
(like your example) with pointers to them in the main table, without
needing to write raw SQL.
On 4. Oct 2007, at 12:51, s.ross wrote:
http://wiki.rubyonrails.org/rails/pages/SingleTableInheritance
Regarding creating the tables with SQL statements. Many, if not most
Rails developers are using migrations. That way you can have a
versionable schema that is independent of the backbone.
Thanks both. I’ll give that a shot.
I know about migrations, I just like to think in raw SQL during the
planning stages of my projects. ;o) That may actually be the biggest
hurdle I’ll have to overcome for working in Rails…
Cheers,
Dav
David Christopher Zentgraf wrote:
WHERE id IN (SELECT a_id FROM b WHERE [condition])… etc.
How would I go about this in rails? Can I abstract these queries to
such a degree in views?
Active Record supports both Single Table Inheritance where you basically
mash all the information into a single table and Polymorphic
Associations where the extra information is kept in separate tables
(like your example) with pointers to them in the main table, without
needing to write raw SQL.
–
Michael W.
Thanks for the detailed explanation.
Every tutorial I had a look at so far began with modelling the tables
using SQL in one way or another and than building Rails on top of
that, getting it to reference the correct tables. Apparently that’s
the wrong way to go…
If I can do all the references from A to B and vice-versa using
classes in Rails I think I’ll be happy.
Regarding that, what’s actually the best way to start an application?
Writing a migration, creating the DB from it, scaffolding the models
and controllers, then doing the has_many :B, :C? Or will those
relations be scaffolded automatically if I’m migrating correctly?
Chrs,
Dav
David Christopher Zentgraf wrote:
and controllers, then doing the has_many :B, :C? Or will those
relations be scaffolded automatically if I’m migrating correctly?
Chrs,
Dav
Hi David,
Rails/ Ruby are all about agility, so, the idea is to do frequent
iterations, adding a little bit at each iteration.
I would start by creating a migration for one of the models and then
creating the model for it. If I was eager to see what it looked like,
I’d create a controller/ scaffold to get it up so that I can enter some
things into the table. Then, I’d go after the next model and so on.
Once both sides of a relationship exist, I’d add the relationships and
add the view/ controller code for managing insertions, etc. (I haven’t
yet used ActivScaffold so I’m not full sure what all it handles).
The second edition of Agile Web D. with Rails does go through a
full-fledged application at the start of the book. While it’s a
real-enough application, it opens up all the key features of Rails. If
you decide to commit to Rails, it is a worthwhile investment. There’s
another book from SitePoint that is available free of charge right now
(58 days and counting down) and it should cover the main concepts too.
Alternatively, look for online tutorials. There are a couple of IBM
Developer Works which take you through your first application that are
not bad, either.
Cheers,
Mohit.
10/4/2007 | 12:28 PM.
Excellent starter indeed, thanks a bunch!
Downloading the sitepoint book as well as we speak.
Tutorial wise, I followed the awfully written OnLamp “Rolling with
RoR” tutorial linked from Ruby on Rails — A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern. and a few
others, but none seemed to have explained the basic getting-started
idea as poignant as you just did.
I didn’t buy any books on Rails just yet since I first wanted to find
out whether it’s the right tool for the job…
Best,
Dav
explained the basic getting-started idea as poignant as you just did.
I think I wanted to say “to the point”. Must’ve been distracted by
the poignant foxes on Ruby on Rails — A web-app framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) pattern.. ;o)