I am writing a rails app, which has some modules and methods loaded via the lib directory, we have also added some methods in restful authentication module, now everytime when i run using mongrel server on production i dont get this error, although because model classes and controller classes are cached, but in development i do get this error, after the first time, so i start my server on development and run once i get the correct behavior, but when i refresh the page i get this nil.include error, while it displays that the each method is getting a nil to iterate, also i have done some homework, as i added the puts method, for all methods for that instance while iterating, i dont get any method definations for attributes of the table, like ID, name, title. i am unsure about this,
I am using Rails 2.2.2 and ruby 1.8.7.
Server is mongrel & webrick.
This situation happened to me, where I used to get the error only after the refresh (i.e., second call to the server).
It may be that you have defined a module in your /lib directory which does not matches the rails convention of file-naming. And you are using the require "filename.rb" statement to get the module.
Try using require_dependency "filename.rb" instead.
Let me know if problem still exists, we may look deeper.
You should look into the log/development.log or log/production.log files (depending on the environment you are investigating). The first line of the stacktrace shows the source of the error. Try to find the error there or post the relevant line (this and some above).
Related
I have a rails which seemed to be working previously but now after some changes when I go to the root page it takes it infinitely to load it, it just doesn't load it. There're nothing useful in the console either. How can I find out what prevents it from loading the main page? Is it about profiling?
Check your Rails logs, eg. development.rb. You can put logger.info, or puts statements in your environment.rb, development.rb and application.rb files to see how far Rails is getting in the boot process. You can also create a dumb initializer named 00_start_init.rb with a logger.info or puts statement to see if you're getting as far as initialization. I've found that useful before.
To really understand where you application is hanging, you need to understand the Rails initialization process. Here is the documentation for Rails version 4.2. http://guides.rubyonrails.org/v4.2/initialization.html. Similar documentation exists for every version of Rails. You can take advantage of understanding the boot sequence by placing log statement at various point in the process.
I'm assuming you're in the development environment. If so, and the console loads, it's likely not a configuration problem. It's more likely a problem with your controllers or models. If the console won't load to a prompt, then it's likely a configuration problem in application.rb, development.rb, an initializer, etc.
You mention profiling, but provide no details about it. I can't even guess what you're referring to, so the answer is "maybe?". If you can post the code changes you made since the app last loaded in the browser, that would make it much easier to help you trouble-shoot.
I upgraded to Rails 4 and now when some changes are made to the code, or when I do a reload! in rails console, I will get an ArgumentError: A copy of ApplicationHelper has been removed from the module tree but is still active! error.
I'm not the only one with this problem but still cant find existing solutions that work yet.
I've never encountered that problem before. I'm using Rails4 as well.
I think you have to call your controller(which is shown in the ArgumentError) explicitly in your dependent controllers.
Can you try adding this line on top inside the class?
require "_controller"
Then try rails server -e production
See if this helps. Sorry I wish I could give you more detailed solution.
If all else fails, rollback might be an option to consider.
I'm having a bizarre issue where it seems as if Rails is skipping the run of my particular Action. I have two environments that I am running this in. One (development) works fine and runs the action. The other (staging) is not running the action.
The error is that Rails can't find a template in the views directories for my given action, which is only supposed to respond with JSON (no template). I've done logging in the action and it just simply isn't being run. Rails immediately fails saying that the view doesn't exist.
Just to cover my bases, I've verified that the code is indeed the same, that my routes file is exactly the same, and that my rails version (3.0.1) is exactly the same between the two env's. Any help would be excellent here.
Apparently this comes in the department of facepalm. One of our developers had committed a new controller with a different file name but the same controller class name as another. It must be that in development rails was loading the new controller first, and so the old controller would override it and the issue was hidden. In stage however, it seems that the new controller was loaded last, which cannibalized our controller class and method, screwing everything up.
I'd be interested to know if others have encountered this problem in rails. May need to patch the controller loading code to always use the same sort mechanism (seems like file name would be most natural).
I am a former PHP developer learning Rails and Sinatra. In PHP, every page request loaded all of the required files. If I changed some code and refreshed the page, I could be sure that the code was fresh.
In Rails 3, Controller code is fresh on every request. However, if I modify any code in the /lib folder, I need to restart the server so the changes take effect.
Why does this happen? Is it something to do with the way Ruby is designed? Is Rails doing some optimizations to avoid reloading code on every request?
Thanks!
Edit: I am mostly interested in what is going on under the hood. Do frameworks like Rails and Sinatra do some special caching for classes? If so, what does they do? Is the default behavior in Ruby that all code gets reloaded on every request? Why do we need tools like Shotgun for Sinatra (http://sinatra-book.gittr.com/#automatic_code_reloading)?
While you are in development mode you should tell Rails not to cache your classes so they reload each time. This means that each request the classes are basically redefined in the rails interpreter. The setting in your Rails.root/config/environments/development.rb:
config.cache_classes = false
The classes the are in your lib/ dir are usually loaded through an initializer and not subject to this setting.
When you move to production you will want all of your classes to be cached so requests are faster and rails will do optimizations to things like scopes on your models.
You could put something in another initializer (maybe called Rails.root/config/initializers/development_reload.rb) that reloads the lib dir with every request in development (or just the ones you are working on):
# file development_reload.rb
if Rails.env.development?
ActionDispatch::Callbacks.after do
load 'filename_in_lib'
# or
Dir.entries("#{Rails.root}/lib").each do |entry|
load entry if entry =~ /.rb$/
end
end
end
I am calling "load" so it actually reloads the file, whereas "require" would just check if it has been loaded and determine it already has so it will not reload it. (I just threw this together and don't use it, but Ruby is extremely flexible and will allow you to do quite a bit.) Use something like this wisely and only in a dev environment.
Why code needs to be reloaded in Rails 3?
Ruby is an interpreted language (JRuby has some support for precompilation, but it's still interpreted). Interpreting the the definition of classes once on initialization is similar to compiling php and deploying in executable format (somewhat). The interpreter is not bothered with redefining classes all the time.
Forcing the explicit reload is an optimization for this type of interpreted language. (if you AOT compile in php you would need to reload the compiled "bytecode" after changes as well; default php uses on-the-fly compilation which is what you are taking advantage of)
How about a more high level approach:
ActionDispatch::Reloader.cleanup!
ActionDispatch::Reloader.prepare!
This was taken from Rails/ActiveRecord v3.2.13 - active_record/railtie.rb
The load approach didn't work for me. Just performing load caused a weird issue where it would trigger certain validators twice for me.
In order to fix that, I tried Object.send(:remove_const, User) before reloading User, but then I lost my observers on that class, so I started chasing my tail.
The above approach reloads all the classes, so maybe there is still yet a better approach to properly remove an individual class from cache and reload it...
I've added an "account" variable to a Rails app I'm running, and tested in the development environment with a mongrel server. Everything worked fine. I set my environment to production and use our Apache server, and suddenly nothing works. After a lot of debugging, I've found that the account variable is succesfullying being SET in my methods, but it's not SAVING (that is, once it gets out of the method that sets it, it's nil). I can call save or save! as many times as I want, and it's still not being set.
The attribute is accessible, and I'm not seeing any errors in the logs... It's just not saving.
Any idea what's going on?
-Jenny
Ah, I migrated to dev, but not production. I didn't think it could be the migrations, because if it were, I reasoned, I wouldn't be able to access #video.account, or whatever, because I would get a "method does not exist" error (which is what I was getting before I migrated in dev).
A bit more information to help you out on why that happened:
Check out the file db/schema.rb - it contains a Ruby representation of your database, updated on each migration. Models in Rails base their attributes on this file.
So when you migrate in development mode, the schema file is updated. When you move to production mode, that file is kept, and Rails doesn't know that the columns you are trying to assign don't exist. As such, the object you update accepts the attribute assignment, sends the query, and moves on - not noticing that the attribute didn't really save.
That's my understanding of it - hope this helps you in your quest!