What are the difference between three modes in rails like:-
In development mode, Rails reloads models each time a browser sends in a request,
so the model will always reflect the current database schema.
EDIT
I was asking about the other differences. I mentioned one i was looking for other list of differences...!!
It comes down to performance and stability. In production mode, model are cached in memory, meaning that once they have been read once, the files don't have to be read again, bringing an obvious speed benefit. This means that if you were to alter the ruby file (eg app/models/page.rb) where a model is defined, this change would not be picked up until the next reload.
By default, the following line is found in config/environments/production.rb:
config.cache_classes = true
The assumption is that when you're in production mode, you won't be changing your code other than via a release or deployment. If you want to clear the cache, you need to restart the application.
The development environment will reload your models each time it receives a request. This is controlled by the following default line in config/environments/development.rb:
config.cache_classes = false
In terms of the 'third' mode, I presume you mean test mode. This also caches models by default (see config/environments/test.rb), again with the assumption that you won't be altering your codebase mid-way through a test run.
Btw, it's not just models - I'm pretty sure that this setting encompasses any classes found within the 'app' directory. In addition, you will find that, even in development mode, classes located elsewhere in the application (eg 'lib') can not be changed without restarting the application.
The behavior of the three modes is configured in:
rails_app/config/environments/[production|development|test].rb
So, it depends on your configuration how the three modes are different.
Related
Sometimes I have to start our application server with the production environment. It always has surprised me that changes saved on development are instantly loaded, while those made on production environment aren't.
What is the reason behind it? How can I change it so anything saved is "seen" on the server?
Thanks.
It's on purpose. Reloading the code between each request requires a reasonable amount of time and resources, therefore it's not advisable for a production environment.
You can change the setting from the production.rb environment configuration
# Code is not reloaded between requests.
config.cache_classes = true
Change it to false.
I suggest you to not make the change permanent on production, rather just toggle the value temporarily if you need to quick check something.
I read a post about the rails load_paths, here is the link.
But, I am still confused about the difference between the autoload_paths and eager_load_paths:
I have tested them in a newly created Rails 4 project. It seems that they run the same way, that auto-reload in the development mode but in the production mode.
Author of the linked article here. Here's an attempt to clear up the confusion, going off of #fkreusch's answer.
In Ruby you have to require every .rb file in order to have its code run. However, notice how in Rails you never specifically require any of your models, controllers, or other files in the app/ dir. Why is that? That's because in Rails app/* is in autoload_paths. This means that when you run your rails app in development (for example via rails console) — none of the models and controllers are actually required by ruby yet. Rails uses special magical feature of ruby to actually wait until the code mentions a constant, say Book, and only then it would run require 'book' which it finds in one of the autoload_paths. This gives you faster console and server startup in development, because nothing gets required when you start it, only when code actually needs it.
Now, this behavior is good for local development, but what about production? Imagine that in production your server does the same type of magical constant loading (autoloading). It's not the end of the world really, you start your server in production, and people start browsing your pages slightly slower, because some of the files will need to be autoloaded. Yes, it's slower for those few initial requests, while the server "warms up", but it's not that bad. Except, that's not the end of the story.
If you are running on ruby 1.9.x (if I recall correctly), then auto-requiring files like that is not thread safe. So if you are using a server like puma, you will run into problems. Even if you aren't using a multi-threaded server, you are still probably better off having your whole application get required "proactively", on startup. This means that in production, you want every model, every controller, etc all fully required as you start your app, and you don't mind the longer startup time. This is called eager loading. All ruby files get eagerly loaded, get it? But how can you do that, if your rails app doesn't have a single require statement? That's where eager_load_paths come in. Whatever you put in them, all the files in all the directories underneath those paths will be required at startup in production. Hope this clears it up.
It's important to note that eager_load_paths are not active in development environment, so whatever you put in them will not be eagerly required immediately in development, only in production.
It's also important to note that just putting something into autoload_paths will not make it eager-loaded in production. Unfortunately. You have to explicitly put it into eager_load_paths as well.
Another interesting quirk is that in every rails app, all directories under app/ are automatically in both autoload_paths and eager_load_paths, meaning that adding a directory there requires no further actions.
Basically, autoload_paths are paths Rails will use to try loading your classes automatically. E.g. when you call Book, if that class isn't loaded yet, it will go through the autoload_paths and look for it in those paths.
In production, it might be better to load those upfront to avoid autoload concurrent issues. For that, it provides the eager_load_paths. Paths in that list will be required upfront when your application starts.
I am working on rails application , in which i am using ruby 1.9.2 and rails 3.0.8. My application is running quite fine in development environment, which includes creating tables from the application and accessing them.
But when i start my application in production environment in which caching is enabled, every thing is working fine , i am not able to access the table which i am creating using my application. I am able to access these tables after restarting the server, which is a pain.
I am searching for a way where i can clear the cache whenever new table get created, can you please help me to clear the cache dynamically.
Thanks
Naveen Kumar Madipally
The one workaround would be to do this in your environments/production.rb (which is not at all recommended on production)
config.cache_classes = false
this will decrease your performance in production but what you can do is fo to production.rb file and check the blow lines
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
i guess it will solve your problem
There are abstractions for that in ActionDispatch::Reloader : it's what's used in development environment to reload classes.
So basically, you would need to run :
ActionDispatch::Reloader.cleanup!
ActionDispatch::Reloader.prepare!
I'm not sure it would be such a good idea, though, as you can't expect which code (yours or from gems) does things that are supposed to happen only once.
Couldn't you use STI rather than dynamicly creating tables ?
I have some iPhone client tests that run against my development rails server. The whole suite runs an order of magnitude faster if I turn on class caching in the Rails config. On the other hand, that slows down development when I'm not actually running the tests.
I want the test suite to hit an action at the beginning to turn on class caching and another action at the end to turn class caching off again.
Is this even possible? If so, how?
Not without some serious hacking. Rails goes to quite a lot of trouble to make sure your files are reloaded on every request (when cache_classes=false). The value of the cache_classes configuration variable is used by initializers in several places not the least of which being:
using require to load ruby files when cache_classes is true (meaning they are no longer reloadable)
setting up dispatcher callbacks to reaload the application on every request when cache_classes is false
You do have access to the value of the cache_classes variable, and you can even change it if you like:
Rails.configuration.cache_classes = true
But, this will have no effect on the running rails instance as the initializers where that value is used only run once when the rails app starts up.
What this means is this, unless you're prepared to invest some serious time and hacking effort you can't really avoid a restart of your server. So, what you need to look at is controlling this restart process via your test suite.
For example you can try to restart rails from within rails. This would allow you to define an action that your test suite can hit right before it begins executing (to restart the server in the right mode), and another action which the server can hit after all tests have finished, to restart everything with cache_classes set to what it used to be. You would control the value of cache classes via an environment variable like this post suggests.
It would still require a bit of work to set all of this up and get it to hang together, but this is probably your best bet if you want an 'auto-magical' solution.
I don't think doing what you suggest will work.
But I suggest you may be looking for the wrong solution.
If what you want is to access your development database from your iphone testing,
then why not add a new environment.
Add a new file config/environments/iphone_dev.rb
require File.dirname(__FILE__)+"/development.rb"
config.cache_classes = true
And in your database.yml (or mongoid.yml or whatever)
iphone_dev:
host: localhost
database: my_app_development
There is no reason the database cant be the same
Now just run rails server -eiphone_dev -p3001
You should have a server, almost the same as your dev server,
but running on a different port, with caching enabled.
I'm new to Ruby on Rails and am creating a test application. So far, it's working, but when I make some minor changes to my views, the page doesn't change.
My problem may be related to this question, but I'm not sure what is meant by setting the date and time in the VM. My code is on a remotely hosted server, so I assume it would use the system time of that machine.
Is there a caching issue here? What can I do about it?
If you don't have control over the server environment yourself (no shell access, etc.), you can set the following at the top of config/environment.rb:
ENV['RAILS_ENV'] = 'development'
Development doesn't cache much, so while it's slower it's much nicer to develop in.
You'll still need to restart your app after making changes to anything outside the app/ folder though (configs, plugins, etc.).
You need to restart your Rails app (or Apache if you are using Passenger) if you are in production mode!