#2389 STI changes behavior depending on environment - Ruby on Rails

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#2389 ✓wontfix

STI changes behavior depending on environment

Reported by Pete P. | April 1st, 2009 @ 04:30 AM | in 2.x

This is a follow up to http://dev.rubyonrails.org/ticke...

and

https://rails.lighthouseapp.com/...

The problem occurs(for me) when cache_classes is set to false. For a pretty version of the code for the test case: http://pastie.org/433401


class FeedEvent < ActiveRecord::Base
end

class ProjectFeedEvent < FeedEvent
end

class ProjectAddedEvent < ProjectFeedEvent
end


#with config.cache_classes = false

#First web request
ProjectFeedEvent.find(:all) 
  => SELECT * FROM `feed_events` WHERE ( (`feed_events`.`type` = 'ProjectFeedEvent' OR `feed_events`.`type` =      'ProjectAddedEvent' ) )

#second web request
ProjectFeedEvent.find(:all) 
  => SELECT * FROM `feed_events` WHERE ( (`feed_events`.`type` = 'ProjectFeedEvent' ) )

Comments and changes to this ticket

You flagged this item as spam.
leh April 1st, 2009 @ 01:06 PM
I'm experiencing the same behavior.
You flagged this item as spam.
Pete P. April 1st, 2009 @ 06:30 PM
As a note, FeedEvent has a polymorphic association
```
  belongs_to :source, :polymorphic => true
```
You flagged this item as spam.
Pete P. April 1st, 2009 @ 07:12 PM
Ok, I've found the offending method(sort of)...

Its ActiveRecord::Base#reset_subclasses

I've attached a simple test case which details it. A couple of key points...if you execute all the preparatory statements in the test case(eg, migration and model creation) in a console, the test case will pass. However, if you create appropriate files for the models and migrations, and then load the console and run the subsequent test code, the test case will fail! The plot thickens...
- active_record_sti_subclass_reload_bug.txt 823 Bytes
You flagged this item as spam.
Pete P. April 1st, 2009 @ 07:44 PM
The work around(ugh...)

You must explicitly name subclasses in the parent class
```
  #for the example above
  class ProjectFeedEvent < FeedEvent
    def self.subclasses
      [ProjectAddedEvent]
    end
  end
```
CancelProfileIsBroken August 6th, 2009 @ 12:55 PM
- Tag changed from “2.3.2, cache_classes, inheritance, single, table” to “2.3.2, bugmash, cache_classes, inheritance, single, table”
You flagged this item as spam.
Peer Allan August 10th, 2009 @ 04:24 AM
verified that the following the steps in the console did duplicate the problem in both master and 2-3-stable. Attempted to verify using the browser when running script/server in development, but was unable to.

Not sure what is going on here. If the classes are all defined in the same model file then the above behaviour occurs. When I separated the model files the SubTest.all used the same SQL before and after the reload of the subclasses.
Tarmo Tänav August 26th, 2009 @ 03:04 PM
This is a very old and somewhat known issue [1] due to the development environment not explicitly loading all classes (unlike the production environment) and thus only being aware of the classes that have been referenced during the current request in some way.

A workaround for this is to make the base class model file cause the subclasses to be loaded aswell by listing them at the bottom of the file:
```
require_association 'subclass1'
require_association 'subclass2'
```
This way when the base class is referenced in development mode it also loads all the listed subclasses (which could then load their own subclasses as well should there be a deeper hierarchy).

I can't see any simple fixes to this issue that don't significantly alter the way the development environment works.

[1] http://dev.rubyonrails.org/ticket/4730
You flagged this item as spam.
John Pignata September 27th, 2009 @ 05:23 AM
-1 - I can't reproduce this using 2.3.4
You flagged this item as spam.
Akira Matsuda September 27th, 2009 @ 07:31 AM
-1 couldn't reproduce on 2.3.4
CancelProfileIsBroken September 27th, 2009 @ 11:41 AM
- Tag changed from “2.3.2, bugmash, cache_classes, inheritance, single, table” to “2.3.2, cache_classes, inheritance, single, table”
- State changed from “new” to “stale”
Staling because appears to be no longer repro, and no patch available. Please reopen if you have additional info or ideas.
You flagged this item as spam.
Marcin 'swistak' Raczkowski October 26th, 2009 @ 10:57 AM
- Tag changed from “2.3.2, cache_classes, inheritance, single, table” to “2.3.2, cache_classes, inheritance, single, table”
+1, still happens here on 2.3.4 in dev mode, with class preloading turned off.

Also it's impossible to override the default behaviour with conditions, since it always adds AND table_name.type="Somthing".
You flagged this item as spam.
Jonathan Dance April 1st, 2010 @ 02:40 AM
- Tag changed from “2.3.2, cache_classes, inheritance, single, table” to “2.3.5, cache_classes, sti”
1. I've reproduced this bug in 2.3.5. It has to do with autoloading, so the classes have to be in separate files. I am guessing those trying to reproduce in the past ran the test case in a single file. The workaround does work (defining self.subclasses).
You flagged this item as spam.
Paul Schreiber November 9th, 2010 @ 10:20 PM
- Importance changed from “” to “”
I reproduced this problem on 2.3.10 and wrote it up on StackOverflow.

Adding require_association didn't work for me, but explicitly listing the subclasses (per Pete P.) did.
Neeraj Singh November 10th, 2010 @ 01:59 PM
- State changed from “stale” to “wontfix”
This is a well documented issue. I will add a link to the document when I find that.