Rails - Jan 2005 - Two questions: relations and scaffolding

1)  ruby script/generate scaffold <entity> will clobber your
<entity>.rb
file.  Is this really what we want?

I''m getting used to Ruby and Rails.  My learning process has gone like
this.

* Play with scaffolding and database structure until the entry pages ask 
for the right thing.

* Load up irb and make sure the (developer) use cases for my entities 
are as I expect in terms of loading and saving to the DB.

* Go back and write the real UI.

In starting step 3, I found out that I''d be having to re-establish a 
couple of relationship entities that had vanished!  This was definitely 
a surprise.

Isn''t scaffolding primarily a "view" issue?  To my noob
brain, when the
tutorials walk me through creating a model, THEN working with the 
scaffolding, why does generating the scaffolding kill the model (and the 
fixtures and the functional tests)?

What is it that I''m not understanding about the real meaning of
scaffolding?

2)  I''m working on a (for now) single-user music database over the web.
    Among others, I have three entities:  Recording (extended by Album 
and LiveShow), Song, and Rating.

Both Recording and Song should be able to be rated.  Thus, I''d normally
expect the tables to look like this:

Recording:
----------
...
rating_id (int)

Song:
-----
...
rating_id (int)

Rating:
-------
id (int)
rating (float)
comment (text)

I''d like the rating to be available as song.rating and
recording.rating.

The problem is that if I put has_one on Recording and Song, I have to 
have song_id and recording_id in the Rating: table.  Not a big deal, but 
  when I do go multi-user, Rating might be the single most populous 
table in the DB, wasting 33% of every row.

If I put belongs_to on Recording and Song then I get the db form I like, 
but no "natural" song.rating field.

Is the best way around this to just add the rating method to Recording 
and Song myself?  Or to do something else with the relationship 
codification?

----

Finally, I''d like to say that I am absolutely thrilled to be a part of 
this community.  I''ve never seen a group where the experts and newbies 
all felt excited to be working on something together.

Cheers,

Jim

Jim Van Fleet wrote:
> If I put belongs_to on Recording and Song then I get the db form I like, 
> but no "natural" song.rating field.
class Song
   belongs_to :rating
end

assert Song.find(1).rating.is_a?(Rating)

This sort of thing ought to work, so I don''t quite understand your 
problem. If this doesn''t work, either you''re setting it up
incorrectly
somehow, or you''ve found some erroneous behaviour in AR. Can you please
expand upon why you think you get ''no "natural" song.rating
field''?

Tim.

-- 
Tim Bates
tim-kZbwfhiKUx26c6uEtOJ/EA@public.gmane.org

Jim Van Fleet wrote:
> 1)  ruby script/generate scaffold <entity> will clobber your
<entity>.rb
> file.  Is this really what we want?
> 
> I''m getting used to Ruby and Rails.  My learning process has gone
like
> this.
> 
> * Play with scaffolding and database structure until the entry pages ask 
> for the right thing.
> 
> * Load up irb and make sure the (developer) use cases for my entities 
> are as I expect in terms of loading and saving to the DB.
> 
> * Go back and write the real UI.
This is one way to do it, others create the UI first as the UI can often 
define design criteria and data relationships that one might miss while 
just thinking them out.  It''s a personal thing, I do both at random.

> In starting step 3, I found out that I''d be having to re-establish
a
> couple of relationship entities that had vanished!  This was definitely 
> a surprise.
Do you mean files that you had made but then were nuked by a generator? 
  I''m not sure I understand what''s going on here for you.
> [...]
> 2)  I''m working on a (for now) single-user music database over the
web.
>    Among others, I have three entities:  Recording (extended by Album 
> and LiveShow), Song, and Rating.
> 
> Both Recording and Song should be able to be rated.  Thus, I''d
normally
> expect the tables to look like this:
> 
> Recording:
> ----------
> ...
> rating_id (int)
> 
> Song:
> -----
> ...
> rating_id (int)
> 
> Rating:
> -------
> id (int)
> rating (float)
> comment (text)
> 
> I''d like the rating to be available as song.rating and
recording.rating.
> 
> The problem is that if I put has_one on Recording and Song, I have to 
> have song_id and recording_id in the Rating: table.  Not a big deal, but 
>  when I do go multi-user, Rating might be the single most populous table 
> in the DB, wasting 33% of every row.
> 
> If I put belongs_to on Recording and Song then I get the db form I like, 
> but no "natural" song.rating field.
> 
> Is the best way around this to just add the rating method to Recording 
> and Song myself?  Or to do something else with the relationship 
> codification?
Have you seen the diagram at 
http://curry.elitists.net/~scott/ARAssociations.png yet?  It might help 
clarify what you want to do.  Some people get confused about the FK 
placement for the has_one relationship (I did, and that''s why I made
the
diagram :), they would want to put a rating_id in Song, as you have. 
The AR way is to have the song_id in the ratings table.  By saying "Song 
has one rating" what it really means is that "there exists ONE rating 
out there with this song''s ID".  Keeping this structure also
allows you
to easily have multiple ratings for a song because the key placement is 
the same.  You would just change  has_one to has_many and then it''s 
meaning "there exist MANY ratings out there with this song''s
ID".

I''m not sure about your conerns for wastage in the database with this 
set up.  What would be wasted?  If song/recording each have a rating_id 
field, or if rating has a song_id and recording_id field, it''s the same
amount of data.  If you make it multi-user then the ratings table could 
certainly be the most populus table since there can be multiple ratings 
per song.

Try setting it up as:
Ratings
-------
id
recording_id
song_id

And I think it should do just want you want (song.rating).  Hopefully I 
haven''t confused you further ;)

-Scott


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails