rails 1.2.5 I've an abstract class as subclass of ActiveRecord::Base . Like this: class SomeAbstractModel < ActiveRecord::Base self.abstract_class = true end I've a table Foo with a column "type", since I've subclasses of Foo. If this class is defined like this class Foo < ActiveRecord::Base end a simple select produces this query: # Foo.find(1) SELECT * FROM foo WHERE (foo."id" = 1) If I change the superclass of Foo to my Abstract Model: class Foo < SomeAbstractModel end the simple select produces now a different query # Foo.find(1) SELECT * FROM foo WHERE (foo."id" = 1) AND ( (foo."type" = 'Foo' ) ) This leads to my problem, since I've some rows where the type is NULL. Why does ActiveRecord behave like that? Well, Foo.superclass.abstract_class? returns true. Any thoughts?
on 22.11.2007 13:05
on 22.11.2007 14:55
Joachim Glauche wrote: > If this class is defined like this > > the simple select produces now a different query > # Foo.find(1) > SELECT * FROM foo WHERE (foo."id" = 1) AND ( (foo."type" = 'Foo' ) ) > > > This leads to my problem, since I've some rows where the type is NULL. > Why does ActiveRecord behave like that? Well, > Foo.superclass.abstract_class? returns true. Any thoughts? I have a patch to remove abstract classes from STI find conditions: http://dev.rubyonrails.org/ticket/9694 However this is just for the efficiency boost. Your type field should never be NULL if you're only creating non-abstract classes in the STI hierarchy, unless it's a legacy issue. -- We develop, watch us RoR, in numbers too big to ignore.
on 22.11.2007 15:05
Mark Reginald James wrote: > Your type field > should never be NULL if you're only creating non-abstract classes > in the STI hierarchy, unless it's a legacy issue. Well, yes it should be never NULL, but I've plenty of those rows where type is NULL (all created by Model#save). I currently cannot reproduce the problem, but it seems to occour in production mode. Maybe because schema info is not updated properly.