rails text_field / text_ara empty string vs nil - ruby-on-rails

Question

I'm not even sure if I have a problem, but I just don't like that my text_fields and text_areas get saved in the db as empty string instead of nil.
I'm playing with the null object pattern and just realized if I create a profile but don't fill in the location field and then call <%= #user.profile.location.upcase %> then it doesn't blow up since location is a string even it it's empty.
Is this the rails convention to have it this way? If so, then why? It's weird a bit since let's say there is a number_of_pets attr on the profile and then I try to call something like
<% if user.profile.number_of_pets.odd? %>
<%= #user.profile.first_name %> has odd number of pets
<% end %>
then it blow's up since I can't call nil.odd?.
form as usual, so it will saved as empty string if not filled
<%= form_for #profile, url: user_profile_path do |f| %>
<%= f.label :city %>
<%= f.text_field :location, class: 'form-control' %>
......

Answer 1

The easiest work around is to use a gem like "strip_attributes" found here: https://github.com/rmm5t/strip_attributes
A custom workaround could be done by adding a before_save callback in your model that takes any values that are blank and sets them back to nil.
In your model for example:
before_save :my_nil_maker_method_lol
[...]
def my_nil_maker_method_lol
if self.whatever_attribute.blank?
self.whatever_attribute=nil
end
end
Update:
Keeping blank fields from being saved could be done several ways such as described above or even deleting blank params in your controller before they hit the database.
The Rails way, when maintaining database integrity, is to always keep this logic inside your model. It makes it much easier to maintain and leaves much less room for surprises like if you were to modify the incoming parameters somewhere else.
As far as how it should be done in the model is really just a matter of what you as the developer expect to get for input. You can add a callback as shown above which maintains your db as you see fit or you can add a validates_presence_of validation that will return an error to the user if that field is left blank.
If you're asking whether you should be keeping empty strings from being inserted into the database at all, it is really up to you as the developer since there may be instances where you might want that information but in this case it sounds as though you're looking to restrict empty strings.

Answer 2

I am speaking from what I observed, and may not necessarily the Rails-convention.
When we do rails g post title content:text for example, you may remember that it does not have default: '' for both title(string) and content(text). This is already a hint to me that there is no Rails-convention regarding this, or specifically speaking every attribute by default is allowed to be NULL or nil.
The advantage of using NULL is that you can identify which records have those attributes set up.
Let's say we have an API server. If a client creates a post to our API server, we know which attributes are intended to have a value. Let's say something like the following:
client-1's POST params:
post: {title: 'Foo bar'}
if NULL-allowed, will create a Post(title: 'Foo bar', content: nil)
if default: '', will create a Post(title: 'Foo bar', content: '')
client-2's POST params:
post: {title: 'Foo bar', content: ''}
if NULL-allowed, will create a Post(title: 'Foo bar', content: '')
if default: '', will create a Post(title: 'Foo bar', content: '')
From above, notice that if we have default: '', then we cannot know if the client is actually intending to have an empty content value, because for both client-1 and client-2, the resulting content value for the post will have '' (empty) anyway. But if we have NULL-allowed attributes, then we can still identify if the client intended to not have a content value by not passing in the attribute in the parameters. This is an important use-case.
Depending on your project and the attribute's purpose, you may either use NULL-allowed or set default empty string for that attribute.
Now, the one main problem with NULL-allowed as you have encountered is that you cannot guarantee that every value will be a String, therefore your <%= #user.profile.location.upcase %> will raise an error in case location is NULL or nil.
This can be a little annoying especially if you have a chain of methods like your example
<%= #user.profile.location.upcase.downcase %>
This will be a problem if #user.profile.location is nil, because you'll have to gracefully ensure that it won't raise an error. And this will also be a problem if #user.profile is nil (let's just say you are allowing #user.profile to be nil). And normally, you'll do something like the following to make this work:
<% if !#user.profile.nil? && !#user.profile.location.nil? %>
<%= #user.profile.location.upcase.downcase %>
<% end %>
That if condition can still go on very long as you have longer chained methods to gracefully ensure it won't raise any error.
Using .try() will potentially "clean" this up. I use this a lot of times especially in template files. Solution will be cleaner like below, albeit potentially confusing for those who do not know:
<%= #user.profile.try(:location).try(:upcase).try(:downcase) %>
If either .location or .upcase is nil, it will return nil, and not raise any undefined method ... for NilClass anymore.