Forum: Ruby on Rails abstract_class causes find to add "and foo."type" = 'Foo'"

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?

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.

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.