Ilan Berci wrote: > First off, I disagree with your use of polymorphism in this problem > domain. You could keep location a top level class along with a status > field which could simply hold the values 'building', or 'deleted'. > Choose sub classing for changes and/or additions to functionality vs > changes and/or additions to state.
In this case, trying to distinguish Building from DeletedLocation would have required a lot of branches and conditionals on that one flag, and I follow the rule-of-thumb that if the program has to change behavior based on a non-displayed state variable, you have to consider refactoring the classes. > Anyways, disregarding the above.. take a look at this excellent podcast > by Bates that explains it as well as any.. > http://railscasts.com/episodes/154-polymorphic-association This did help, thank you. What misled me was that I'd hoped setting an ActiveRecord relation could "just work" in the way other object references do. Obviously, on reflection, the engine has to be assured that the DB plumbing is in place. So I added a building_type column to Person, changed Person's belongs_to line to belongs_to :building, :polymorphic => true and SharedLocation's has_many line to has_many :people, :dependent => :nullify, :as => :building Thanks again. — F -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
