After install Devise I try to run
**rake db:migrate**
but it gives:
**rake aborted!
stack level too deep**
I'm on Ubuntu, changed
**ulimit -s unlimited**
and checked, it works, but still have the error.
I use RVM, tried to work out with Ruby1.9.2-p180, Ruby-1.9.2-p0, with Rails 3.0.9, Rails 3.1rc4, with Rubinius.
Tried with SQLite3 and with PostgreSQL.
Tried to uncomment as many as I can from the migration file.
Read all related Stackoverflow posts (and realized what I have is actually named StackOverflow).
Any help would be highly appriaciated! Many thanks
stack level too deep errors typically result from infinite recursion problems.
New Answer:
I forgot this was occurring during db:migrate. Is something in your users table migration relying on something that would rely on it?
Old Answer:
It would be helpful for you to show the lines of code you have in your routes.rb file for devise. For example, you might have:
devise_for :users, :controllers => { :registrations => "registration/foo" }
In this example, take a look at the new method in foo_controller.rb. If that method redirects to another controller that causes you to attempt to register again, you will have an infinite recursion.
The first thing I would do is look at what controllers are being called by putting some sort of debug output in your controllers. Try:
logger.debug("i am in foo")
or
puts "i am in bar"
If you can provide more information, I may be able to help more.
Have you tried bundle exec rake db:migrate?
Related
I'm upgrading a very old rails application step by step. At the moment I am stuck at Rails 3.1. I did all the relevant steps for upgrading. For now I don't want to use assets so I disabled it in config/application.rb.
As soon as a change the rails version in my Gemfile from 3.0.20 to 3.1.12 I get a no-route-matches error. I also changed all upgrading steps back to 3.0 to see which part causes the error but it happens only when I change the line in the Gemfile.
My routes.rb:
Wawi::Application.routes.draw do
match ":controller(/:action(/:id(.:format)))"
end
Please tell me if you need more code.
rake routes:
/:controller(/:action(/:id(.:format)))
(and a warning: circular argument reference)
Maybe another useful hint: The action is part of the Application Controller.
are you calling Object#to_i on your object inside your url helper? may be the object is nil and nil.to_i is always 0. And also note, rails primary id starts from 1.
So you should give a try with running rake routes:
ruby bundle exec rake routes
After running that command you should see your url list that are available based on your route file.
Thanks to a colleague I found the solution:
In application_controller.rb session :session_key => '...' had to be changed to Rails.application.config.session_options[:key] = '...'.
I'm struggling with this for quite a while now: I'm trying to upgrade an app from Rails 3.2 to Rails 4. While on Rails 3.2 all specs are passing, they fail under certain conditions in Rails 4.
Some specs are passing in isolation while failing when run together with other specs.
Example Video
https://www.wingolf.org/ak-internet-files/Spec_Behaviour.mp4 (4 mins)
This example video shows:
Running 3 specs using :focus–––green.
Running them together with another spec–––two specs passing before now fail.
Running the 3 specs, but inserting two empty lines–––one spec fails.
Undo does not help when using guard.
focus/unfocus does not help.
Restarting guard does not help.
Running all specs and then running the 3 specs again does help and make them green again. But adding the other task makes two specs fail, again.
As one can see, some specs are red when run together with other specs. Even entering blank lines can make a difference.
More Observations
For some specs, passing or failing occurs randomly when run several times.
The behavior is not specific to one development machine but can be reproduced on travis.
To delete the database completely between the specs using database_cleaner does not help.
To Rails.cache.clear between the specs does not help.
Wrapping each spec in an ActiveRecord::Base.transaction does not help.
This does occur in Rails 4.0.0 as well as in Rails 4.1.1.
Using this minimal spec_helper.rb without spring or anything does not help.
Using guard vs. using bundle exec rspec some_spec.rb:123 directly doesn't make a difference.
This behavior goes for model specs, thus doesn't have to do anything with parallel database connections for features specs.
I've already tried to keep as many gems at the same version as in the (green) Rails-3.2 branch, including guard, rspec, factory_girl, etc.–––does not help.
Update: Observations Based on Comments & Answers
Thanks to engineerDave, I've inserted require 'pry'; binding.pry; into one of the concerning specs. Using the cd and show-source of pry, it was ingeniously easy and fun to narrow down the problem: Apparently, this has_many :through relation does not return objects when run together with other specs, even when called with (true).
has_many(:groups,
-> { where('dag_links.descendant_type' => 'User').uniq },
through: :memberships,
source: :ancestor, source_type: 'Group'
)
If I call groups directly, I get an empty result. But if I go through the memberships, the correct groups are returned:
#user.groups # => []
#user.groups(true) # => []
#user.memberships.collect { |m| m.group } # returns the correct groups
Has Rails changed the has many through behavior in Rails 4 in a way that could be responsible? (Remember: The spec works in isolation.)
Any help, insights and experiences are appreciated. Thanks very much in advance!
Code
Current master branch on Rails 3.2––all green.
Rails-4 branch––strange behavior.
The file/commit seen in the video––strange behavior.
All specs passing on travis for Rails 3.2.
Diff of the Gemfile.lock (or use git diff master..sf/rails4-minimal-update Gemfile.lock |grep rspec)
How to Reproduce
This is how one can check if the issue still exists:
Preparation
git clone git#github.com:fiedl/wingolfsplattform.git
cd wingolfsplattform
git checkout sf/rails4-minimal-update
bundle install
# please create `config/database.yml` to your needs.
bundle exec rake db:create db:migrate db:test:prepare
Run the specs
bundle exec rspec ./vendor/engines/your_platform/spec/models/user_group_membership_spec.rb
bundle exec rspec ./vendor/engines/your_platform/spec/models/user_group_membership_spec.rb:213
The problem still exists, if the spec :213 is green in the second call but is red when run together with the other specs in the first call.
Based on that you're using:
the should syntax
that you indicate you've upgraded recently (perhaps a bundle update?)
that your failure messages indicate a NilObject error.
Is something like this perhaps what is causing it?
https://stackoverflow.com/a/16427072/793330
Are you are calling an object in your test which hasn't been instantiated yet?
I think this might be an rspec 3 upgrade issue where should is deprecated.
Have you ruled out an rspec gem upgrade to the new rspec 3 syntax (2.99 or 3.0.0+) as the culprit?
"Remove support for deprecated expect(...).should. (Myron Marston)"
IMO this behavior would not be caused by a Rails 4 update as its centered around your test suite.
Update (with pry debug):
Also you could use the pry gem to get a window into what is going on in your specs.
Essentially you can put a big "stop" sign (similar to a debug break) right before the spec executes to get a handle on the environment at that point.
it {
require 'pry'; binding.pry
should == something
}
Although beaware sometimes these pry calls wreck havoc on guard's threading and you have to kill it with CTRL+Z and then kill -9 PID that shows.
Update #2: Looking at updated answer.
You might be running up against FactoryGirl issues based on your has_many issue
You may need to trigger a before action in your Factory to pre-populate the associated record. Although this could get messy, i.e. here be monsters, you can trigger after and before callbacks in your factory that will bring these objects into being.
after(:create) do |instance|
do stuff here
end
I'm using the latest version of the Impressionist and Rails Admin gems, and wondering if anyone could shed some light on an annoying conflict I'm experiencing. The problem is roughly documented here - https://github.com/sferik/rails_admin/issues/1315, yet the vaguely described solution is not working for me. When I have the line is_impressionable in my Listing model, I get an error when starting my Rails server with rails s:
...rvm/gems/ruby-2.0.0-p247/gems/activerecord-4.0.2/lib/active_record/dynamic_matchers.rb:22:in `method_missing': undefined local variable or method `is_impressionable' for Listing(no database connection):Class (NameError)
If I first start the server, and then add the 'is_impressionable' line, everything works fine, so the problem only occurs during initialization. I don't fully understand the initialization process, so am not sure how to go about getting this to work.
I have tried moving all my rails_admin model configuration options to their respective models, rather than in the initializer, which had no effect. I also have the following line in my initializer:
config.included_models = [Listing,ListingImage,AllOtherModelsHere...]
I have tried adding single quotes around these model names, which results in the following errors, as described in the github issue here
[RailsAdmin] Could not load model Listing, assuming model is non existing. (undefined local variable or method `is_impressionable' for Listing(no database connection):Class)
Any ideas what else I can try to make these gems work together? I don't want to have to remove the is_impressionable line every time I want to restart the server or generate a migration...
Not sure if the same issue that I had but yet I will post what worked for me just in case someone struggles with this too:
Im on a ruby 2.1.5 project with rails 4.2.0 and among other gems I'm using rails admin.
I run into several weird problems trying to set this up. For instance if I added the is_impressionable call within one of my models for some reason the execution of that file stopped there and I started getting weird errors like any method declared below the is_impressionable failed with undefined error.
So what I end up doing was:
class MyModel < ActiveRecord::Base
include Impressionist::IsImpressionable
is_impressionable
end
So this solved my issue and now i can access #my_model_instance.impression_count as expected.
I changed every occurrence of Klass to 'Klass'.constantize in initializer.
i'm developing a rails 3 engine but really having troubles getting the
controller to load every time.
every second time I visit the page I get;
LoadError in Webedit/public filesController#index
Expected /home/anko/.rvm/gems/ruby-1.9.2-p136/bundler/gems/webedit-3e02394235c3/app/controllers/public_files_controller.rb
to define PublicFilesController
to reproduce (assuming bash, ruby 1.9.2 and rails 3);
rails new webedit-test
cd webedit-test
echo "gem 'webedit', :git => 'https://github.com/ankopainting/webedit.git', :tag => 'v0.0.3'" >> Gemfile
bundle install
rails server
then goto http://localhost:3000/public
it will either say "hi" or an error.. refresh to see it change to the
opposite behaviour.
any help would be greatly appreciated.. I've spent some time in ruby
debugger but need to understand a lot about how rails works to get a
meaningful result.
I used the source code you provided and added a directory under controllers. Seems to work fine now. Since you have the controller inside a module, you need to create this directory structure:
app/controllers/webedit/public_files_controller.rb
Not exactly sure why it was loading every other time, though.
After following a tutorial Ive found. Im now redoing it again, without the scaffolding part, to learn it better.
However, editing my \app\views\home\index.html.erb to contain:
<h1>Rails test project</h1>
<%= link_to "my blog", posts_path>
I get an error:
undefined local variable or method `posts_path' for #<ActionView::Base:0x4e1d954>
Before I did this, I ran rake db:create, defined a migration class and ran rake db:migrate, everything without a problem.
So the database should contain a posts table. But that link_to command cant seem to find posts_path. That variable (or is it even a function?) is probably defined through the scaffold routine.
My question now is; how do I do that manually myself, define posts_path?
You will need to define a path to your posts in config/routes.rb
Rails 2.x syntax:
map.resources :posts
Rails 3.x syntax:
resources :posts
The _path methods are dynamically generated typically. The method missing error comes about when there isn't a route to the object specified or in this case the method you're calling explicitly.
Defining a route should fix this. HermanD above showed one way to do this.
You can run 'rake routes' from the root of your rails app to see all the routes that are configured
<%= link_to "my blog", posts_path>
If this is exactly what your erb contained, it's missing the percent sign at the end of the scriptlet element. Not sure if that caused your problem, or maybe I'm taking things too literally....