aliyun Elastic Compute Service
app_danci#iZ2ze599ua4y0nvsppbmjhZ:~/myproject$ rails c -e production
Running via Spring preloader in process 13978
Loading production environment (Rails 5.1.4)
2.3.1 :001 > u = User.first
NameError: uninitialized constant User
from (irb):1
2.3.1 :002 > User.all
NameError: uninitialized constant User
from (irb):2
Why can I not see the model User?
You're probably missing something. I think you have a migration for a users table. Have you run rails db:migrate? If so, maybe you have just the table but you have not defined the class User?
class User < ApplicationRecord
end
or maybe is your class User defined inside a module?
The common error, one can make is not using appropriate nested Namespaces. If your models are defined under a namespace please use it in your console too. It can be called by using a qualifying names such as ::Namespace::Model. It is highly unlikely that rails console loads fine and can't seem to call the Rails Model. Hope this helps.
Related
I recently decided to change the name of a model. So I dropped the DB calling rails db:drop.
Using sublime text editor I did a find & replace for the model name, and I renamed all relevant directories to be in line with convention; including the migration file etc.
I deleted the schema file.
I called rails db:create to create the DB: no errors
I called rails db:migrate to create the tables and schema: no errors.
When I try to call a method on the model class... ('Set')
> Set.all
NoMethodError: undefined method `all' for Set:Class
from (pry):4:in `<main>'
For a test, I ran rails generate model Set and got the following:
Running via Spring preloader in process 2042
invoke active_record
The name 'Set' is either already used in your application or reserved by Ruby on Rails. Please choose an alternative and run this generator again.
So here it seems the model does exist. But it doesn't exist in console.
Why is my model nil
It's not. It's unclear where you drew this conclusion from.
NoMethodError: undefined method `all' for Set:Class
Name of your model (Set) is the same as class from the standard lib. Due to how rails' autoloading works, name Set is resolved to the stdlib class, not your model. Rename your model with a non-existing name (just as the warning suggests).
Unable to use rspec and rollbar after upgrading to rails 5.
Create a Rails 4 app
Upgrade gemfile to use rails 5
Try adding rollbar gem/support
Standard config/environment.rb:
# Load the Rails application.
require_relative 'application'
# Initialize the Rails application.
Rails.application.initialize!
Error when running rspec:
An error occurred while loading {path to specific spec file}
Failure/Error: require File.expand_path('../../config/environment', __FILE__)
RuntimeError:
can't modify frozen Array
# ./config/environment.rb:6:in `<top (required)>'
# ./spec/rails_helper.rb:5:in `<top (required)>'
...
No examples found.
In most cases, that error is a red herring for something else.
When encountering it, don't get overwhelmed with the recurrent can't modify frozen Array error messages, and instead check the very first error that appears when running a spec.
For example:
Failure/Error: validate :uniqueness, if: 'should_be_unique?'
ArgumentError: Passing string to be evaluated in :if and :unless
conditional options is not supported. Pass a symbol for an instance
method, or a lambda, proc or block, instead.
Just to add one tip on top of Maxximo Mussini's answer.
If anyone can't find the first error on the terminal, please try to run RSpec on one file, i.e. rspec spec/models/user_spec.rb
You should be able to find the root case.
In my case, I haven't updated my local .env variables that is required by User model
Hope it helps
Debugging this is not easy but one possible solution is simple. It could be a naming conflict with Rollbar, possibly something getting monkey-patched. If you're seeing this RuntimeError but not using Rollbar, see other answer.
Add a Module ("namespace" of your choice) around your app class definition in config/application.rb.
The module won't affect much. The only difference I could find is when printing out your app it will now appear as (that's how we found the fix vs a new working app):
<MyTestAPP::Application ...> instead of <Application ...>
Change:
class Application < Rails::Application
# Initialize configuration defaults for originally generated Rails version.
config.load_defaults 5.1
end
To:
Module MyTestApp
class Application < Rails::Application
# Initialize configuration defaults for originally generated Rails version.
config.load_defaults 5.1
end
end
I'm trying to add Active Admin to a Rails app that already has a bespoke CMS and Admin model living at path /admin, and which already uses the devise gem, but when I try to run rails g active_admin:install followed by rake db:migrate, I get this error:
/usr/local/rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/activeadmin-0.6.0/lib/active_admin/namespace.rb:227:in `eval': Admin is not a module (TypeError)
from /usr/local/rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/activeadmin-0.6.0/lib/active_admin/namespace.rb:227:in `eval'
from /usr/local/rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/activeadmin-0.6.0/lib/active_admin/namespace.rb:227:in `register_module'
from /usr/local/rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/activeadmin-0.6.0/lib/active_admin/namespace.rb:41:in `initialize'
from /usr/local/rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/activeadmin-0.6.0/lib/active_admin/application.rb:142:in `new'
from /usr/local/rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/activeadmin-0.6.0/lib/active_admin/application.rb:142:in `namespace'
from /usr/local/rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/activeadmin-0.6.0/lib/active_admin/application.rb:128:in `register'
from /usr/local/rbenv/versions/1.9.2-p290/lib/ruby/gems/1.9.1/gems/activeadmin-0.6.0/lib/active_admin.rb:79:in `register'
I know it's possible to set a default namespace in the initializer that the install creates, but I wondered if there was a way to pass a default namespace of my choosing in as an option with the install command?
Thanks in advance!
OK - finally figured it out:
I kept the active_admin.rb initializer created when I ran the Active Admin install command the first time, and deleted every other file that it had created. I then added this line to the initializer:
config.default_namespace = :my_custom_admin_namespace
and ran the install again, skipping the Devise user class (as suggested here), like so:
rails g active_admin:install --skip-users
I ran my migrations, and I was then able to visit myapp.co.uk/my_custom_admin_namespace. At first I did see an error about an unknown method regarding authenticating users (which makes sense given I skipped creating the user class), so I commented out the following two lines in the initializer:
config.authentication_method = :authenticate_admin_user!
config.current_user_method = :current_admin_user
and now I can see the dashboard. It's not an ideal setup yet since it's lacking the user class and any authentication, but it's a start.
I have a fresh app with only a few gems. Devise being one of them of course. And when I make an Admin model via Devise's Option 1 give here
... and upload to heroku, I am unable to run a db:migrate due to the following error:
rake aborted!
uninitialized constant Admin
/app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/inflector/methods.rb:230:in block in constantize'
/app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/inflector/methods.rb:229:ineach'
/app/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/inflector/methods.rb:229:in constantize'
/app/vendor/bundle/ruby/1.9.1/gems/devise-2.1.2/lib/devise.rb:256:inget'
/app/vendor/bundle/ruby/1.9.1/gems/devise-2.1.2/lib/devise/mapping.rb:77:in to'
/app/vendor/bundle/ruby/1.9.1/gems/devise-2.1.2/lib/devise/mapping.rb:72:inmodules'
/app/vendor/bundle/ruby/1.9.1/gems/devise-2.1.2/lib/devise/mapping.rb:89:in routes'
/app/vendor/bundle/ruby/1.9.1/gems/devise-2.1.2/lib/devise/mapping.rb:156:indefault_used_route'
etc...
Does anyone have any suggestions?
Created another fresh rails app and everything is working now. I believe the problem might have been that I created my Admin model with a capital "A" and some code was looking for an admin model with a lowercase "a"
What's the Rails 3 replacement for ActiveRecord::Errors?
In Rails 2.3.8, this is an object:
>> ActiveRecord::Errors
=> ActiveRecord::Errors
In Rails 3.0.0rc, you get a NameError:
>> ActiveRecord::Errors
NameError: uninitialized constant ActiveRecord::Errors
from (irb):2
I'm trying to make the wizardly generator work with Rails 3.
$ rails g wizardly_scaffold home
But it fails:
/Library/Ruby/Gems/1.8/gems/wizardly_gt-0.1.8.9/lib/validation_group.rb:150:
uninitialized constant ActiveRecord::Errors (NameError)
The line it refers to is this:
ActiveRecord::Errors.send :include, ValidationGroup::ActiveRecord::Errors
Earlier in the file, we see:
module ValidationGroup
module ActiveRecord
...
module Errors # included in ActiveRecord::Errors
def add_with_validation_group(attribute, msg = I18n.translate('activerecord.errors.messages')[:invalid], *args, &block)
add_error = #base.respond_to?(:should_validate?) ? (#base.should_validate?(attribute.to_sym) || attribute == :base) : true
add_without_validation_group(attribute, msg, *args, &block) if add_error
end
...
end
That'd be ActiveModel::Errors. Things such as validations and error handling have been moved over to Active Model to provide a common API for all ORM Railties such as Active Record, Data Mapper, Mongoid etc. to hook into Rails with.
It would appear the wizardly plugin needs to check for ActiveModel first and if it exists, then include the error handling there rather than ActiveRecord::Errors. A trivial change.
Try this gem
http://rubygems.org/gems/wizardly_gt
I have only just begin playing with wizardly, but the above at least seems to be compatible with Rails 3.
Wizardly obviously does a lot more, but you should check out validation_scopes, which I just updated for Rails3 compatibility. Rather than grouping things by attributes, it just lets you explicitly declare different groups of validations by creating namespaced collections of errors. Internally it's a much simpler implementation (the same code handles Rails 2 and 3). Personally I find this to be more flexible than grouping by attribute (what if an attribute should have different constraints in different steps of a wizard for instance?).