Rails - May 2005 - has_many and belongs_to associations to arbitrary tables in ActiveRecord?

I''m not entirely sure how to explain my query more generally, so I will
try to just give an example from my application. I have an Article 
class, and a Newsletter class, and a User class, and a few others, and 
I wish records for each of these classes to have Attachments associated 
with them. I also want to do this with as few tables and classes as 
possible. I don''t want to have both an ArticleAttachment class and a 
NewsletterAttachment class, or have both a articles_attachments table 
and a attachments_newsletters table.

So, what I''ve done is create an Attachment class, and an attachments 
table, which has ''record_table'' and
''record_id'' fields, corresponding
to the table and record id each Attachment belongs to.

In Attachment, it seems like this association would be appropriate:

      belongs_to :record, :class_name =>
''#{record_table.classify}'',
:foreign_key => ''record_id''

However, this doesn''t work. When I attempt to use the record 
association, I get the error "undefined method `find'' for 
nil:NilClass". The ''culprit'' is the :class_name value --
when that''s
set to something like ''Newsletter'', it works fine. Is there
something
I''m missing in how ''#{record_table.classify}'' is
parsed?

I''m having difficulties in the other classes that need to have 
attachments, too. In the Newsletter class, for example, I have the 
following association:

     has_many :attachments, :foreign_key => ''record_id'',
:conditions =>
"record_table = ''newsletters''"

This works alright, except that I can''t add attachments to the 
association properly without explicitly specifying the record_table 
field.

     @newsletter.attachments << Attachment.create(:record_table => 
''newsletters'');

Is there some way to add maybe a callback or something in the model to 
automatically add this extra association? I would like to instead 
write:

     @newsletter.attachments << Attachment.create();


Very thankful in advance,

- Michael Daines

I''d re-examine your desire to use a single table. If the attachment
types
only relate to a single table, then there is no data benefit from forcing 
them into a single table. You might be making unnecessary work for yourself.


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

> I''d re-examine your desire to use a single table. If the
attachment
> types
> only relate to a single table, then there is no data benefit from 
> forcing
> them into a single table. You might be making unnecessary work for 
> yourself.
There is one attachment type, but it may relate to any other table in 
the database. An Artist has many Works, and I wish to have Attachments 
associated with a Artist and Attachments associated with a Work. An 
inheritance thing should take place as well. From a Work, the 
attachments belonging to that Work''s User should also be available, but
other Artists shouldn''t be able to see that Artist''s
attachments, and
other Works shouldn''t be able to see that Work''s attachments.

Elsewhere in the app, this same thing should exist: An Article needs to 
have attachments for itself, and so does a Newsletter, and an Article 
needs to inherit a Newsletter''s attachments.


- Michael Daines

I have a similar dilemma, so I''m mostly presenting a counter view to
test my
theory. I have Articles and Events, each needs related Comments. I think
I''m
going with Article_comments and Event_comments. I also need comments on 
those comments, but I''m stopping there and putting the child comments
in the
same tables to allow n generations of children. I''m attracted to fewer 
tables, but not at the expense of complicating the application without 
adding functionality. I may be wrong, hopefully someone will show me if I 
am. 

If you have Artists and Works it seems more straight forward (easier) to 
implement Artist_Attachments and Work_Atachments than Attachments. The 
Artists will inherit the attachments of their Works, because the Artists are 
related to their Works. Likewise a Newsletter can inherit its Articles 
attachments, because the Articles are associated to the Newsletter. Artist 
attachments, Works attachments, Article attachments and Newsletter 
attachments have nothing (no relationships) in common. You can put them in 
the same Table, but it just seems to add model complexity, not 
functionality.

Several shorter directly associated tables should be easier to develop with 
and faster for the db to use than one large table with complex associations. 
At the limit, you could develop your entire application with only one table 
but obviously this would be more work than its worth just to achieve a goal 
of a minimum number of tables.

Your thoughts? These great theories of mine allways have holes :-)


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