This comments out requiring action_mailer/railtie
It also omits mailer specific configurations
such as config.action_mailer.raise_delivery_errors and
config.action_mailer.perform_caching in production/development
and config.action_mailer.delivery_method by default
in test environment.
As, we can see action_mailer/railtie is commented out.
The security threat we had was that
it was possible for an attacker to issue
unexpected database queries with “IS NULL” where clauses.
Though there was no threat of an insert being carried out,
there could be scope for firing queries that would check for NULL
even if it wasn’t intended.
In later version of Rails(> 3.2), we had a different way of handling
blank arrays in Active Record find_by and where clauses.
As you can see a conditional for empty array
doesn’t trigger IS NULL query, which solved part of the problem.
We still had conversion of empty array to nil
in the deep munging in place and hence there was still
a threat of undesired behavior when request contained
One way to handle it was to add before_action hooks
to the action that could modify the value to empty array
if it were nil.
Let’s see what happens with the POST request without specifying the response.
Rails happily returns with 204: No content response in this case.
This means users get the feel that nothing happened in the browser. Because Rails
returned with no content and browser happily accepted it.
But in reality, the user record was created in the database.
what happens with the GET request
in Rails 5.
Instead of 204: No Content, we get ActionController::UnknownFormat exception.
Rails is being extra smart here and hinting that we are probably missing
corresponding template for this controller action. It is smart enough to show us
this message as we requested this page via browser via a GET request.
But if the same request is made
via Ajax or through an API call or a POST request, Rails will return 204: No Content response as seen before.
In general, this change can trip us in the development phase, as we are used
to incremental steps like adding a route, then the controller action and then
the template or response. Getting 204 response can give a feel of nothing happening
where things have actually happened in the background. So don’t forget to respond properly
from your controller actions.
In Rails 4.x
create_join_table allows us to create new join table with name given in first two arguments.
It will create new join table customer_products with columns customer_id and product_id.
We can also use block with create_join_table.
However create_join_table won’t allows us to define the column type.
It will always create column of integer type.
Because Rails 4.x ,by default, supports primary key column type as an auto increment integer.
If we wish to set uuid as a column type, then create_join_table won’t work.
In such case we have to create join table manually using create_table.
Here is an example with Rails 4.x.
Rails 5 allows to have UUID as column type in join table
Rails 5 has started supporting UUID as a column type for primary key, so create_join_table should also support UUID as a column type instead of only integers.
Hence now Rails 5 allows us to use
UUID as a column type with create_join_table.
Rails 5 has added another base class
which inherits from ActiveJob::Base.
Now by default all new Rails 5 applications will have application_job.rb.
In Rails 4.x if we want to use
then first we need to generate a job and all the generated jobs directly inherit from ActiveJob::Base.
Rails 5 adds explicit base class ApplicationJob for ActiveJob.
As you can see this is not a big change but it is a good change in
terms of being consistent with how controllers have
Now ApplicationJob will be a single place to apply all kind of customizations and extensions needed for an application, instead of applying patch on ActiveJob::Base.
Upgrading from Rails 4.x
When upgrading from Rails 4.x to Rails 5 we need to create application_job.rb
and add the following content.
We also need to change all the existing job classes to inherit from ApplicationJob instead of ActiveJob::Base.
Here is the revised code of GuestCleanupJob class.
Sometimes while debugging production issue
mistakenly developers execute commands
RAILS_ENV=production rake db:schema:load.
This wipes out data
Users of heroku download all the config variables to local machine to
debug production problem and sometimes developers mistakenly
execute commands which wipes out production data.
This has happened enough number of times to heroku users that
of heroku decided to do something about this issue.
Rails 5 prevents destructive action on production database
a new table ar_internal_metadata to store
environment version which is used
at the time of migrating the database.
When the first time rake db:migrate is executed then
new table stores the value production.
Now whenever we load
by running rake db:schema:load or rake db:structure:load
Rails will check if Rails environment is “production” or not.
If not then Rails will raise an exception and thus preventing
the data wipeout.
To skip this environment check
we can manually pass DISABLE_DATABASE_ENVIRONMENT_CHECK=1
as an argument with load schema/structure db command.
Here is an example of running rake db:schema:load
when development db is pointing to production database.
As we can see Rails prevented data wipeout in production.
This is one of those features which hopefully you won’t notice.
However if you happen to do something destructive to your
production database then this feature will come in handy.
Before Rails 5, we could fetch all time zones for US by using us_zones method as follows.
Such functionality of getting all the TimeZone objects for a country was implemented only for one country, US.
The TimeZone class internally uses the TzInfo gem which does have an api for providing timezones for all the countries.
Realizing this, the Rails community decided to
introduce a helper method country_zones
to ActiveSupport::TimeZone class that is able to fetch a collection of TimeZone objects
belonging to a country specified by its ISO 3166-1 Alpha2 code.
Fragment cache helps in caching parts of the view instead of caching the entire view.
Fragment caching is used when different parts of the view need to be cached and expired separately.
Before Rails 5, fragment caching was supported only in Action View templates.
In Rails 4.x we have transactional fixtures that wrap each test in a database transaction.
This transaction rollbacks all the changes at the end of the test.
It means the state of the database, before the test
is same as after the test is done.
By default this functionality is enabled.
We can choose to disable it in a test case class
by setting the class attribute use_transactional_fixtures to false
Rails also comes with fixtures for tests.
So it may seem that use_transactional_fixtures has something to do with the Rails fixtures.
A lot of people don’t use fixtures and
they think that they should disable use_transactional_fixtures because
they do not use fixtures.