Using
WebView
in a React Native application
allows us to reuse already built web pages.
We have seen that in most of the “web view” based applications the links
in header are mostly turned in native navigational components.
It means server should not be sending header if React Native component
is asking for web pages.
However those headers should be present if the
request is not coming from the React Native app.
Passing custom request headers
We can configure React Native app to pass custom request headers
when request is made to the server to fetch pages.
$ rails new my_app --skip-action-mailer# OR$ rails new my_app -M
This comments out requiring action_mailer/railtie
in application.rb.
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.
We use accepts_nested_attributes_for when
we want a single form to cater to multiple models.
By using this we can easily
provide attributes for associated models.
In Rails 4.x,
if a validation fails
for one or more of the associated models,
then it is not possible to figure out from error message,
which of the associated model object is the error related to.
classProduct<ApplicationRecordhas_many:variantsaccepts_nested_attributes_for:variantsendclassVariant<ApplicationRecordvalidates:display_name,:price,presence: trueend>>product=Product.new(name: 'Table')>>variant1=Variant.new(price: 10)>>variant2=Variant.new(display_name: 'Brown')>>product.variants=[variant1,variant2]>>product.save=>false>>product.error.messages=>{:"variants.display_name"=>["can't be blank"],:"variants.price"=>["can't be blank"]}
In the example above
we can see that if this error message is sent as JSON API,
we cannot find out which variant save failed because of which attribute.
This works well when we render forms using Active Record models,
as errors are available on individual instances.
But, the issue arises with an API call,
where we don’t have access to these instances.
Rails 5 allows indexing of errors on nested attributes
In Rails 5,
we can add an index
to errors on nested models.
We can add the option index_errors: true to has_many
association to enable this behavior on individual association.
classProduct<ApplicationRecordhas_many:variants,index_errors: trueaccepts_nested_attributes_for:variantsendclassVariant<ApplicationRecordvalidates:display_name,:price,presence: trueend>>product=Product.new(name: 'Table')>>variant1=Variant.new(price: 10)>>variant2=Variant.new(display_name: 'Brown')>>product.variants=[variant1,variant2]>>product.save=>false>>product.error.messages=>{:"variants[0].display_name"=>["can't be blank"],:"variants[1].price"=>["can't be blank"]}
Using global configuration
In order to make this change global,
we can set configuration config.active_record.index_nested_attribute_errors = true
which is false by default.
In older Rails version (< 3.2), when an empty array was passed
to a where clause or to a find_by query, it generated SQL
with an IS NULL clause.
User.find_by_email([]).to_sql#=> "SELECT * FROM users WHERE email IS NULL"User.find_by_email([nil]).to_sql#=> "SELECT * FROM users WHERE email IS NULL"
Also, when JSON data of the request was parsed
and params got generated the deep munging converted empty arrays to nil.
For example, When the following JSON data is posted to a Rails controller
This in combination with the fact that Active Record
constructs IS NULL query when blank array is passed
became one of the security threats and
one of the most complained issues in Rails.
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.
User.find_by_email([]).to_sql#=> "SELECT "users".* FROM "users" WHERE 1=0 LIMIT 1"User.find_by_email([nil]).to_sql#=> "SELECT * FROM users WHERE email IS NULL"
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
empty array.
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.
In Rails 5,
empty array does not get converted to nil
in deep munging.
With this change, the empty array will persist as is
from request to the params in the controller.
This format for writing tests with JSON type
is lengthy and needs too much information to be passed to request as well.
Improvement with Rails 5
In Rails 5,
we can provide
Mime type while sending request
by passing it with as option
and all the other information like headers and format will be passed automatically.
Before Rails 5,
when we forget to add template for an action,
we get ActionView::MissingTemplate exception.
classUsersController<ApplicationControllerdefindex@users=User.allendendStartedGET"/users"for::1at2016-06-1017:10:40+0530ProcessingbyUsersController#index as HTMLCompleted500InternalServerErrorin5msActionView::MissingTemplate(Missingtemplateusers/index,application/indexwith{:locale=>[:en],:formats=>[:html],:variants=>[],:handlers=>[:erb,:builder,:raw,:ruby]}...
Similarly, if we don’t specify response for a POST request,
we will also get ActionView::MissingTemplate exception.
Started POST "/users"
Processing by UsersController#create as HTML
Parameters: {"utf8"=>"✓", "user"=>{"name"=>"Max"}, "commit"=>"Create User"}
(0.1ms) begin transaction
SQL (2.7ms) INSERT INTO "users" ("name", "created_at", "updated_at") VALUES (?, ?, ?) [["name", "Max"], ["created_at", 2016-06-10 12:29:09 UTC], ["updated_at", 2016-06-10 12:29:09 UTC]]
(0.5ms) commit transaction
No template found for UsersController#create, rendering head :no_content
Completed 204 No Content in 41ms (ActiveRecord: 3.3ms)
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.
Let’s see
what happens with the GET request
in Rails 5.
ActionController::UnknownFormat (UsersController#index is missing a template for this request format and variant.
request.formats: ["text/html"]
request.variant: []
NOTE! For XHR/Ajax or API requests, this action would normally respond with 204 No Content: an empty white screen. Since you're loading it in a web browser, we assume that you expected to actually render a template, not… nothing, so we're showing an error to be extra-clear. If you expect 204 No Content, carry on. That's what you'll get from an XHR or API request. Give it a shot.):
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.
As we can see, the error occurs due to
absence of method each on an ActionDispatch::Request::Session object.
In Rails 5, each method
was introduced to ActionDispatch::Request::Session
class making it compatible with Rack frameworks mounted in Rails
and hence avoiding the above mentioned errors in integration testing.
As we can see the request id tag is not prepended to the lines containing error details.
If we search the log file by the request id then the error details would not be shown.
Database schemas change rapidly as project progresses. And
it can be difficult to track purpose of each table
and
each column in a large project with multiple team members.
The solution for this problem is to document data models right from Rails migrations.
Currently only MySQL and PostgreSQL supports adding comments.
We can add comments in migration as shown below.
classCreateProducts<ActiveRecord::Migration[5.0]defchangecreate_table:products,comment: 'Products table'do|t|t.string:name,comment: 'Name of the product't.string:barcode,comment: 'Barcode of the product't.string:description,comment: 'Product details't.float:msrp,comment: 'Maximum Retail Price't.float:our_price,comment: 'Selling price't.timestampsendadd_index:products,:name,name: 'index_products_on_name',unique: true,comment: 'Index used to lookup product by name.'endend
When we run above migration output will look as shown below.
➜rails_5_apprakedb:migrate:upVERSION=20160429081156==20160429081156CreateProducts:migrating===================================--create_table(:products,{:comment=>"Products table"})->0.0119s--add_index(:products,:name,{:name=>"index_products_on_name",:unique=>true,:comment=>"Index used to lookup product by name."})->0.0038s==20160429081156CreateProducts:migrated(0.0159s)==========================
The comments are also dumped in db/schema.rb file for PostgreSQL and MySQL.
db/schema.rb of application will have following content after running products table migration .
ActiveRecord::Schema.define(version: 20160429081156)do# These are extensions that must be enabled in order to support this databaseenable_extension"plpgsql"create_table"products",force: :cascade,comment: "Products table"do|t|t.string"name",comment: "Name of the product"t.string"barcode",comment: "Barcode of the product"t.string"description",comment: "Product details"t.float"msrp",comment: "Maximum Retail Price"t.float"our_price",comment: "Selling price"t.datetime"created_at",null: falset.datetime"updated_at",null: falset.index["name"],name: "index_products_on_name",unique: true,using: :btree,comment: "Index used to lookup product by name."endend
We can view these comments with Database Administration Tools such as MySQL Workbench or PgAdmin III.
PgAdmin III will show database structure with comments as shown below.
-- Table: products
-- DROP TABLE products;
CREATE TABLE products
(
id serial NOT NULL,
name character varying, -- Name of the product
barcode character varying, -- Barcode of the product
description character varying, -- Product details with string data type
msrp double precision, -- Maximum Retail price
our_price double precision, -- Selling price
created_at timestamp without time zone NOT NULL,
updated_at timestamp without time zone NOT NULL,
CONSTRAINT products_pkey PRIMARY KEY (id)
)
WITH (
OIDS=FALSE
);
ALTER TABLE products
OWNER TO postgres;
COMMENT ON TABLE products
IS 'Products table';
COMMENT ON COLUMN products.name IS 'Name of the product';
COMMENT ON COLUMN products.barcode IS 'Barcode of the product';
COMMENT ON COLUMN products.description IS 'Product details with string data type';
COMMENT ON COLUMN products.msrp IS 'Maximum Retail price';
COMMENT ON COLUMN products.our_price IS 'Selling price';
-- Index: index_products_on_name
-- DROP INDEX index_products_on_name;
CREATE UNIQUE INDEX index_products_on_name
ON products
USING btree
(name COLLATE pg_catalog."default");
COMMENT ON INDEX index_products_on_name
IS 'Index used to lookup product by name.';
If we update comments through migrations, corresponding comments will be updated in db/schema.rb file.
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.
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
ApplicationJob
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
ActiveJob
then first we need to generate a job and all the generated jobs directly inherit from ActiveJob::Base.
# app/jobs/guests_cleanup_job.rbclassGuestsCleanupJob<ActiveJob::Basequeue_as:defaultdefperform(*guests)# Do something laterendend
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
ApplicationController
and
models have
ApplicationRecord.
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
file in
app/jobs/
and add the following content.
The update_all method when called on an ActiveRecord::Relation object updates all the
records without invoking
any callbacks and validations on the records being updated.
We can see that failure of validations on records in the relation
does not stop us from updating the valid records.
Also the return value of update on AR Relation
is an array of records in the relation.
We can see that the attributes in these records
hold the values that we wanted to have after the update.
For example in the above mentioned case, we can see
that in the returned array, the records with ids 1, 2 and 3
have blank note_text values even though those records weren’t updated.
Hence we may not be able to rely on the return value to know if the
update is successful on any particular record.
For scenarios where running validations and callbacks is not important and/or
where performance is a concern it is advisable to use update_all method instead of update method.
Sometimes while debugging production issue
mistakenly developers execute commands
like
RAILS_ENV=production rake db:schema:load.
This wipes out data
in production.
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
Richard Schneeman
of heroku decided to do something about this issue.
Rails 5 prevents destructive action on production database
Rails 5
has added
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
database schema
or
database structure
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.
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.
This configuration specifies whether mailer templates should perform fragment caching or not.
By default, this is set to false for all environments.
Fragment caching in views
We can do caching in mailer views similar to application views using cache method.
Following example shows usage of fragment caching in mailer view of the welcome mail.
<body><% cache 'signup-text'do%>
<h1>Welcometo<%= @company.name %></h1>
<p>You have successfully signed up to <%=@company.name%>, Your username is:
<% end %><%= @user.login %>.
<br />
</p>
<%=render:partial=>'footer'%></body>
When we render view for the first time, we can see cache digest of the view and its partial.
Cachedigestforapp/views/user_mailer/_footer.erb:7313427d26cc1f701b1e0212498cee38Cachedigestforapp/views/user_mailer/welcome_email.html.erb:30efff0173fd5f29a88ffe79a9eab617Rendereduser_mailer/_footer.erb(0.3ms)Rendereduser_mailer/welcome_email.html.erb(26.1ms)Cachedigestforapp/views/user_mailer/welcome_email.text.erb:77f41fe6159c5736ab2026a44bc8de55Rendereduser_mailer/welcome_email.text.erb(0.2ms)UserMailer#welcome_email: processed outbound mail in 190.3ms
We can also use fragment caching in partials of the action mailer views with cache method.
Fragment caching is also supported in multipart emails.
This returns ActiveRecord::Relation object,
which is logical union of
two relations.
Some Examples of OR usage
With group and having
>>posts=Post.group(:user_id)>>posts.having('id > 3').or(posts.having('title like "Hi%"'))SELECT"posts".*FROM"posts"GROUPBY"posts"."user_id"HAVING((id>2)OR(titlelike"Rails%"))=><ActiveRecord::Relation[#<Post id: 3, title: "Hi", user_id: 4>,#<Post id: 6, title: "Another new blog", user_id: 6>]>
With scope
classPost<ApplicationRecordscope:contains_blog_keyword,->{where("title LIKE '%blog%'")}end>>Post.contains_blog_keyword.or(Post.where('id > 3'))SELECT"posts".*FROM"posts"WHERE((titleLIKE'%blog%')OR(id>3))=><ActiveRecord::Relation[#<Post id: 4, title: "A new blog", user_id: 6>,#<Post id: 5, title: "Rails blog", user_id: 4>,#<Post id: 6, title: "Another new blog", user_id: 6>]>
With combination of scopes
classPost<ApplicationRecordscope:contains_blog_keyword,->{where("title LIKE '%blog%'")}scope:id_greater_than,->(id){where("id > ?",id)}scope:containing_blog_keyword_with_id_greater_than,->(id){contains_blog_keyword.or(id_greater_than(id))}end>>Post.containing_blog_keyword_with_id_greater_than(2)SELECT"posts".*FROM"posts"WHERE((titleLIKE'%blog%')OR(id>2))ORDERBY"posts"."id"DESC=><ActiveRecord::Relation[#<Post id: 3, title: "Hi", user_id: 6>,#<Post id: 4, title: "A new blog", user_id: 6>,#<Post id: 5, title: "Another new blog", user_id: 6>,<#Post id: 6, title: "Another new blog", user_id: 6>]>
Constraints for using OR method
The two relations must be structurally compatible,
they must be scoping the same model, and
they must differ only by WHERE or HAVING.
In order to use OR operator,
neither relation should have a limit, offset, or distinct.
>>Post.where(id: 1).limit(1).or(Post.where(:id=>[2,3]))ArgumentError:Relationpassedto#or must be structurally compatible. Incompatible values: [:limit]
When limit, offset or distinct is passed only with one relation,
then it throws ArgumentError as shown above.
As of now, we can use limit, offset or distinct
when passed with both the relations and with same the parameters.
Rails 5
introduces Array Inquirer
that wraps an array object and provides friendlier methods
to check for the presence of elements
that can be either a string or a symbol.
