Thanks all... I ended up solving this much along the lines that Tim recommended - lots of 'has_many' statements in the School model and several custom built accessors such as those that Tim described.
I appreciate the help. Yoram On Mar 4, 9:29 am, Matt Jones <[email protected]> wrote: > On Mar 3, 4:42 pm, Yoram <[email protected]> wrote: > > > I'm staying away from STI because I want to be able to add additional > > asset types over time, none of which share attributes with other > > assets. So - with STI, I could end up with a table that has hundreds > > of columns. > > And this is a problem because...? Sounds an awful lot like premature > optimization. > > This sort of thing is not supported well by Rails, as it's tricky to > handle in general (after all, one could create additional subclasses > of Asset on-the-fly so Rails can't be sure which tables it should be > querying) and even if possible wouldn't support some operations > cleanly - imagine trying to paginate the assets association... > > One thought was using a join model with a polymorphic belongs_to and > has_many :through, but that won't work either: > > http://stackoverflow.com/questions/1683265/activerecord-has-many-thro... > > One thing that *might* work would be to have a model that holds the > common attributes that then belongs_to the specific types. Not > optimal, but might work with some usage patterns. > > I'm assuming the models you're using are generic examples and not the > real models, so I'll skip addressing the fact that there are very few > operations / actions that make sense applied to both 'Chair' and > 'Teacher'. Even including both in a single list would seem pretty > peculiar. > > --Matt Jones -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
