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.
A project we recently worked on needed some complicated charts.
Now we need to build mobile app using
and it would take a
lot of time to build those charts natively. So we decided to use
to render the html pages which already displays charts nicely.
React Native comes with WebView
component by default.
So rendering the html page using WebView was easy.
However, once the page is rendered the React Native app could not exchange
any data with the web page.
In this blog post we’ll discuss how to
make React Native app communicate with the pages rendered using
with the help of
What is React Native WebView Bridge ?
a wrapper on top of React Native’s WebView component with some extra features.
Now let’s create a basic React component.
This component will be responsible for rendering html page using
After the component is mounted then we will send data to web view.
Next, We will add code to receive data from web view.
At this time code should look something like this.
Okay, We’ve added all the React Native side of code.
example in the README
since it provides more control and flexibility.
Coming back to our implementation, Let’s now add the snippet in our web page.
Done! We’ve achieved our goal of having a two way communication channel between our React Native app and the web page.
for more examples of how to use WebView Bridge.
Somtimes we need to ignore a database column.
However Rails 4.x doesn’t have any officially defined method
which ignores a database column from Active Record.
We can apply our patch on model to ignore certain columns.
In Rails 4.x,
it is not possible to have destroy dependency on both sides
of a bi-directional association between the two models
as it would result in an infinite callback loop
causing SystemStackError: stack level too deep.
Calling User#destroy or Profile#destroy
would lead to an infinite callback loop.
We earlier stated that after_commit callback is executed at the end
of transaction. Using after_commit with a transaction block can be
tricky. Please checkout our earlier post about
Gotcha with after_commit callback in Rails
In this case,
we do not get
about the type of failed validation
ActiveModel#Errors only gives
the attribute name and the translated error message.
This works out well for normal apps.
But in case of API only applications,
we want to allow
the client consuming the API
to generate customized error message as per their needs.
We don’t want to send the final translated messages in such cases.
if we could just send details
that presence validation failed for :name attribute,
the client app would be able to customize the error message
based on that information.
In Rails 5,
it is now possible
to get such details about which validations failed for a given attribute.
We can check this by calling
on the ActiveModel#Errors instance.
We can also add
custom validator types
as per our need.
Passing contextual information about the errors
We can also send contextual data for the validation to the Errors#add method.
This data can be later accessed
via Errors#details method
because Errors#add method
forwards all options except :message, :if, :unless, and :on to details.
For eg. we can say that the password is invalid because ! is not allowed, as follows.
Adding a nice looking background to a screen makes an app visually appealing.
It also makes the app look more sleek and elegant.
Let us see how we can leverage this technique in React Native and add an image as a background.
We’ll need to create different sizes of the background image, which we’re going to use
as a container.
React Native will pick up appropriate image based on the device’s dimension (check
for more information).
Now we’ll use these images in our code as container.
We’ve intentionally left height and width of the image as undefined.
This will let React Native take the size of the image from the image
This way, we can use Image component as View and add other components as a children to build UI.