-
Notifications
You must be signed in to change notification settings - Fork 438
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scientist::Experiment.new creates Scientist::Default instance even when it should have been overridden #92
Comments
Scientist::Experiment.new
creates Scientist::Default
instance even when it should have been overridden
For the moment I've moved this block of code into an initializer: module Scientist::Experiment
def self.new(name)
LdapExperiment.new(name: name)
end
end Which seems to work, so maybe it's just worth noting that strategy in the README |
I also ran into this problem and got around it by using the initializer above |
Super late response but maybe it helps someone else :) Rails lazy loads classes in development. So, your experiment file has not been loaded yet and thus, the default experiment has not been overridden. That's why it works after you instantiate your experiment once which forces Rails to load the file. |
|
I did that, and it's ugly class User < ApplicationRecord
# Force loading of class otherwise `scientist` load the default
# experiment class which is not what we want
DefaultExperiment # our custom class that is enabled withe proper result
extend Scientist # because it is on class method
end |
Hi friends! Thank you for your great work with this gem ✨
I am having a problem in Rails apps where Scientist::Experiment defaults to the original
Default
object until the custom one is called - leading to some head-scratching about why thetry
block is not running even whenenabled?
is set totrue
.I'm unsure whether this is a problem with the Rails load order because of how I've arranged my files, whether the examples in the README could be a little better, or whether there's genuinely a bug here.
I've followed the instructions in the README, which are delightful and comprehensive.
This is occurring in Rails 3.2.x and Rails 5.1.x applications, with version 1.2.0 of the gem.
The text was updated successfully, but these errors were encountered: