This project is archived and is in readonly mode.

#2389 ✓ wontfix
Pete P.

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

  • leh

    leh April 1st, 2009 @ 01:06 PM

    I'm experiencing the same behavior.

  • Pete P.

    Pete P. April 1st, 2009 @ 06:30 PM

    As a note, FeedEvent has a polymorphic association

    
      belongs_to :source, :polymorphic => true
    
  • Pete P.

    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...

  • Pete P.

    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

    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
  • Peer Allan

    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

    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

  • John Pignata

    John Pignata September 27th, 2009 @ 05:23 AM

    -1 - I can't reproduce this using 2.3.4

  • Akira Matsuda

    Akira Matsuda September 27th, 2009 @ 07:31 AM

    -1 couldn't reproduce on 2.3.4

  • CancelProfileIsBroken

    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.

  • Marcin 'swistak' Raczkowski

    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".

  • Jonathan Dance

    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).
  • Paul Schreiber

    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

    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.

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Tickets have moved to Github

The new ticket tracker is available at https://github.com/rails/rails/issues

Shared Ticket Bins

Attachments

Referenced by

Pages