Rails' abilities fitting?

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

David Zentgraf wrote:

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

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:

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)

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.

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.

I'll have a look whether that can do anything for me, thanks. :slight_smile:

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

David Christopher Zentgraf wrote:

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?

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.

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

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:

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
  
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 Development 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 http://www.rubyonrails.org/docs 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 http://www.rubyonrails.org/docs. ;o)