In one subclass of an ActiveRecord based model (using Single Table Inheritance), I override one of the attributes to be calculated, as opposed to looking at the data stored in the database. (Example: Product''s have a price field stored in the DB, but PerishableProduct''s price field is calculated based on other factors...). So far, so good. *But*, I''m concerned about Product.find_by_price. I know that this uses SQL to find things, which, in this case, will be wrong. I''d like to override .find_by_price, to do the search in Ruby (and not in SQL), so that it can check the calculated field. But, this is complicated, because a) find_by_price is a generated method and b) there are other combinations: find_by_color_and_price . I could just avoid using that method, but since other people will be working on that code later, I''m concerned that someone won''t realize and will use it. Besides, I''d like to use consistent names for consistent ideas, even if the implementation changes (isn''t that what OO is about?). I''ve thought of a few hacks to handle this, but I''m looking for a more elegant, integrated solution. Any ideas? -- Posted via http://www.ruby-forum.com/.
List Recv wrote:>In one subclass of an ActiveRecord based model (using Single Table >Inheritance), I override one of the attributes to be calculated, as >opposed to looking at the data stored in the database. (Example: >Product''s have a price field stored in the DB, but PerishableProduct''s >price field is calculated based on other factors...). > >So far, so good. > >*But*, I''m concerned about Product.find_by_price. I know that this uses >SQL to find things, which, in this case, will be wrong. I''d like to >override .find_by_price, to do the search in Ruby (and not in SQL), so >that it can check the calculated field. But, this is complicated, >because a) find_by_price is a generated method and b) there are other >combinations: find_by_color_and_price . > >I could just avoid using that method, but since other people will be >working on that code later, I''m concerned that someone won''t realize and >will use it. Besides, I''d like to use consistent names for consistent >ideas, even if the implementation changes (isn''t that what OO is >about?). > >I''ve thought of a few hacks to handle this, but I''m looking for a more >elegant, integrated solution. Any ideas? > > >Try overriding method_missing. If it is a find_by_price variant raise an exception. If not call super. Jack
On 11/25/05, Jack Christensen <jack-BsDU1ACF2Bglk5EcyZIkJQ@public.gmane.org> wrote:> List Recv wrote: > > >In one subclass of an ActiveRecord based model (using Single Table > >Inheritance), I override one of the attributes to be calculated, as > >opposed to looking at the data stored in the database. (Example: > >Product''s have a price field stored in the DB, but PerishableProduct''s > >price field is calculated based on other factors...). > > > >So far, so good. > > > >*But*, I''m concerned about Product.find_by_price. I know that this uses > >SQL to find things, which, in this case, will be wrong. I''d like to > >override .find_by_price, to do the search in Ruby (and not in SQL), so > >that it can check the calculated field. But, this is complicated, > >because a) find_by_price is a generated method and b) there are other > >combinations: find_by_color_and_price . > > > >I could just avoid using that method, but since other people will be > >working on that code later, I''m concerned that someone won''t realize and > >will use it. Besides, I''d like to use consistent names for consistent > >ideas, even if the implementation changes (isn''t that what OO is > >about?). > > > >I''ve thought of a few hacks to handle this, but I''m looking for a more > >elegant, integrated solution. Any ideas? > > > > > > > Try overriding method_missing. If it is a find_by_price variant raise an > exception. If not call super.I think I would refrain from messing with method_missing: class Foo < AR::Base def self.find_by_price raise "Don''t use this method!!!" end end -- rick http://techno-weenie.net
technoweenie wrote:> class Foo < AR::Base > def self.find_by_price > raise "Don''t use this method!!!" > end > endI thought of this, but what about all the permutations: find_by_price_and_color, etc. -- Posted via http://www.ruby-forum.com/.
List Recv wrote:>technoweenie wrote: > > >>class Foo < AR::Base >> def self.find_by_price >> raise "Don''t use this method!!!" >> end >>end >> >> > >I thought of this, but what about all the permutations: >find_by_price_and_color, etc. > > >That''s why I suggested overriding method_missing. Untested -- but should work def self.method_missing( method_id, *args ) if method_id.to_s.include?(''find_by'') && method_id.to_s.include?(''price'') raise ''Don''t use this.'' else super end end Jack _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails