I have a model named 'Task' in my project.
I upgraded from Rails 3.0 to Rails 3.1 and now I receive the following error. My code hasn't changed.
>> Task.new
WARNING: Deprecated reference to top-level constant 'Task' found at: /Library/Ruby/Gems/1.8/gems/rake-0.8.7/lib/rake.rb:2470:in `rakefile_location'
Use --classic-namespace on rake command
or 'require "rake/classic_namespace"' in Rakefile
ArgumentError: wrong number of arguments (0 for 2)
from (irb):1:in `initialize'
from (irb):1:in `new'
from (irb):1
I'm scared I've called my model something that should have been reserved, what should I do for best practice? Refactor and change the name? Or something else?
Update: I tried it's suggestion of updating the Rakefile, but this did not work.
In the end, it turns out 'Task' has been a reserved word for a long time. I used text mate's find and replace to do a refactor, and created migrations to update the database. It only took about an hour, and I feel it was worthwhile to avoid future problems.
I dug a bit deeper and found this out:
When my specs auto-load the Task constant, Rake's const_missing (source code) kicks in, issues that warning (source code) and returns Rake::Task. Which makes my specs fail because I'm now testing that instead of my model.
I then get a lot of these:
NoMethodError:
undefined method `enqueue' for Rake::Task:Class
Well, of course it doesn't implement enqueue — that's not my model!
So, in short, Rake tells me not to use their top-level Task (even though I didn't mean to), and provides me with a different constant, effectively breaking the auto-loading in Rails!
There's only way around that — I had to manually require 'task' in the spec. Now it's all ponies and rainbows.
Dear Jim Weinrich, if you read this: Next time you declare something deprecated, please ensure that you only warn people about this when they actually use a deprecated API!
Another way to handle this is to get rid of rake's deprecation warning. In your spec_helper, before any activity that would reference the model, do this:
# Rake defines a const_missing that, if you reference any of several
# top-level constants, issues a deprecation warning and then defines
# it. Since Rake defines it, rail's own const_missing doesn't
# happen, and our own class doesn't get loaded. The workaround is to
# remove rake's const_missing.
class Module
def const_missing(*args)
rake_original_const_missing(*args)
end
end
We could have renamed our model, but that was more work than this. This, however, might break with future versions of rake. Choose your poison.
Related
We are getting this error on all local setups of our project(currently) when we call any method like:
belongs_to :abc
after_create :some_method
def some_method
if self.abc.saved_change_to_parent_id?
...
// or even self.abc.parent_id_before_last_save
end
It gives:
NameError (undefined local variable or method `first' for ActiveRecord::NullMutationTracker:Class):
app/models/model_name.rb:50:in `some_method'
Yes, there is not a full trace with rails internal file paths etc, i only get my project files trace. Maybe its some logger config issue, any help to get full trace will also be appreciated.
There are no such issues i could find on internet, thats why posting here.
PS: Not posted on rails issue tracker(github issues) because i don't have minimal reproduction.
Stack
ruby: 2.4.3
rails: 5.1.5 (also tried on 5.1.7)
OS: Ubuntu 20, also tried on macOS
Thanks in advance.
UPDATE1: Using byebug, i got to this trace, where error is occuring:
/Users/dev/.rvm/gems/ruby-2.4.3/gems/acts_as_singleton-0.0.8/lib/acts_as_singleton.rb:43
which is here, so it is not directly from rails, but a very outdated gem we have in our code for some reason.
As i posted in the update, issue was not with rails or anything, i used byebug to track trace and it was something like:
activemodel-5.1.5/lib/active_model/attribute_methods.rb:384
activerecord-5.1.5/lib/active_record/attribute_methods/dirty.rb:146
activerecord-5.1.5/lib/active_record/attribute_methods/dirty.rb:319
activerecord-5.1.5/lib/active_record/attribute_methods/dirty.rb:315
acts_as_singleton-859f49112c03/lib/acts_as_singleton.rb:43
The last line, should not be there, as we are not using acts_as_singleton on any of the involved models.
So after some tracking, it turned out issue with the gem. I have created a fork and used that fork. Here is the fork: https://github.com/ziaulrehman40/acts_as_singleton (forked it from another fork, which seemingly had some other fixes as well). And you can see my changes here.
What was the issue?
This gem writes a module named Singleton within ActiveRecord module. Which seems ok, unless you realize that there is another module named Singleton already. Whihc is being included in:
gems/activerecord-5.1.5/lib/active_record/attribute_mutation_tracker.rb:83
class NullMutationTracker # :nodoc:
include Singleton
...
So as you can see, this Singleton module gets overriden(or expanded, not sure) un-intentionally by that outdated gem(acts_as_singleton).
I am using a development script file to check out new possible ideas. Recently I tried to monkey patch MyDBObject from within that script file.
Assume an empty dev.rb file and add a monkey patch right in the top like so:
class MyDBObject
def test_function
'function works'
end
end
Starting up the pry console and loading the file yields random results.
First I received:
NoMethodError: undefined method `relations' for MyDBObject:Class
Later the script loaded, but I couldn't access the original class any longer:
undefined method `first' for MyDBObject:Class
I noticed that prepending the line:
MyDBObject
right before the monkey patching, the intended functionality is achieved.
This appears to be some sort of lazy loading of the class objects. Can somebody cast some light on this for me please?
Depending on the order in which source files are loaded, you'll either be redefining the entire class, or having your changes replaced.
I highly recommend giving this a read: http://www.justinweiss.com/articles/3-ways-to-monkey-patch-without-making-a-mess/ (TLDR - put your patch in a module and explicitly include it)
My Rails 4/Ruby 2 app is throwing the following warning every time my RSpec tests create a FactoryGirl object: "DEPRECATION WARNING: This dynamic method is deprecated. Please use e.g. Post.find_or_create_by(name: 'foo') instead."
This warning is not thrown when I run my app in development. Is FactoryGirl's code throwing this? I tried to find some information but it doesn't look like other people are getting this.
If you tell Rails to give you a full stack trace for the deprecation warning, you should be able to diagnose it pretty easily. The warnings are coming from a library called ActiveSupport::Deprecation - tell it to run in debug mode.
# config/environments/test.rb
ActiveSupport::Deprecation.debug = true
For me, the warnings were caused by an old version of the Stringex library.
FactoryGirl would make a new model, which would trigger a call to one of the Stringex methods, which would raise the warning, although there was no way to see that until I turned on full stack traces. bundle update stringex solved the issue with no problem.
It looks like it's coming from ActiveRecord.
module DeprecationWarning
def body
"#{deprecation_warning}\n#{super}"
end
def deprecation_warning
%{ActiveSupport::Deprecation.warn("This dynamic method is deprecated. Please use e.g. #{deprecation_alternative} instead.")}
end
end
I'm not sure why you're not getting the warnings in development. Is your environment suppressing the warnings?
I'm writing tests for a Gem and after a couple of hours trying to get rid of this, decided to look around - and to my surprise, there's not a single reference to it on Google (apart from one on mongoid, where people simply ignored it).
So, the problem is simple: I have this block on my test initialization:
class ActiveSupport::TestCase
fixtures :all
end
but the tests fail to execute:
`<class:TestCase>': undefined method `fixtures' for ActiveSupport::TestCase:Class (NoMethodError)
The gem depends on Rails 3 and every dependency is checked & double-checked. The code is on github, in case anyone wants to check (https://github.com/herval/acts_as_recommendable)
I'm out of ideas. Anyone share a light?
I'm not sure, but it seems that fixtures cannot be used with mongoid.
Take a look at this for further details:
https://groups.google.com/forum/?fromgroups=#!topic/mongoid/tqlx3j88Lqw
It's been a long time since I used Rails' built in testing, so take this with a grain of salt. I'm guessing that the actual ActiveSupport::TestCase class hasn't actually been loaded before the initializer is being reached.
It might be enough to just add require 'test_help' at the top of the initializer.
I'm upgrading my Rails app to work with Ruby 1.9 and I keep encountering errors like this:
Anonymous modules have no name to be referenced by
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:585:in `to_constant_name'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:391:in `qualified_name_for'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:104:in `rescue in const_missing'
/home/foo/.gem/ruby/1.9.1/gems/activesupport-2.3.8/lib/active_support/dependencies.rb:94:in `const_missing'
/home/foo/app/config/environment.rb:66:in `block in <top (required)>'
etc.
Google finds all kinds of hits for this, but each of them pertains to a specific fix for one specific gem or app. None of them explain what the message really means.
What is an "anonymous module"?
Where is this error message coming from? (The Ruby interpreter itself?)
What is different about Ruby 1.9 that causes this? (Rails 2.3.8 with Ruby 1.8.7 does not encounter this.)
What is the general/proper way to fix this error?
Line 66 of environment.rb is the configuration for super_exception_notifier (old version, 2.0.8):
ExceptionNotifier.configure_exception_notifier do |config|
config[:sender_address] = %("Foo" <foo#foo.com>)
config[:exception_recipients] = %w(foo#foo.com)
config[:skip_local_notification] = false
end
From what I can tell, ExceptionNotifier is undefined, and ActiveSupport is trying to magically load it, but fails and then fails again trying to print a nice error message.
An anonymous module is a module that is declared like so:
Fred = Module.new do
def meth1
"hello"
end
def meth2
"bye"
end
end
instead of by using the regular Module mod_name <block> syntax. Since they have no module name, you can't retrieve the module name. to_constant_name is attempting to call desc.name.blank? where desc is an anonymous module (with no name).
This error is coming from the ActiveSupport module, which may indicate a bug in the active_support gem or may indicate that some other piece of code is using ActiveSupport incorrectly. The error message alone doesn't give enough information to identify the culprit (to me at least, someone with more rails experience might be able to provide more insight).
Without knowing the offending code it's also hard to say exactly why this error is popping up with 1.9, or what needs to be done to fix it. Considering that there are a lot of un- and under-maintained gems out there that have not been updated for 1.9 yet, I would suspect that ActiveSupport is not the source of the problem. Upgrade all of your gems that have 1.9-compatible versions, and then try disabling your other gems one at a time (if you can) and see if you still get the error.
If you provide a list of the other gems that you are using, someone else who may have encountered the error before may be able to provide some details.
This may happen if you try to exploit ActiveRecord's internal class and module contexts in the wrong way. I had this error yesterday while working on a gem which extends deep inner workings of ActiveRecord. I finally managed to get around this problem by redesigning my code which exploits the inner contexts. It would be interesting to see the surrounding lines of environment.rb:66 for further analysis.
This may happen when the class name doesn't match the filename, in
my case it was a file named application.rb contaning the ApplicationController
class. Renaming the file to application_controller.rb solved the problem.
When I got this error, it was due to a misspelling while defining a class. If you are getting this error, it may be worth examining your module and class definitions for typos.