opensoul.org - Validations on empty (not nil) attributes Comments

Comment on 'Validations on empty (not nil) attributes' by neil

2008-06-17T19:27:07Z

Since I definitely did need to allow for a few not-null columns, but I wanted all the rest of my columns (in a large, dynamic schema) to always be nil if empty, I modified the plugin slightly to check the column definition to make sure it allows null, before converting to nil:

def clear_empty_attrs
  # set any empty-string attributes to nil if the column allows null
  @attributes.each do |key,value|
    self[key] = nil if value.blank? && self.class.columns_hash[key].null
  end
end

Comment on 'Validations on empty (not nil) attributes' by andres

2008-05-21T15:25:22Z

well, there’s built in :allow_blank => true to use instead or alongside with allow_nil

Comment on 'Validations on empty (not nil) attributes' by Marcello Golfieri

2008-03-03T16:53:41Z

Yeah, actually my solution does work flawlessy in each scenario without any of the eventual drawbacks cited here. Nevertheless, having a dedicated :allow_nil would definitely be welcome. In fact, even if adding 3 characters to the regexp looks even faster than typing ”:allow_nil => true”, it does create some confusion on newcomers. Adding the option :allow_nil here too would standardize its use; people obviously expects that option for validates_format_of too (I was one of those, darn it!) Last but not least, “Convention” is cooler than “Configuration”, isn’t it?... (I just wonder where I got this from… ;-) Should be added to next Rails’ wish list.

Comment on 'Validations on empty (not nil) attributes' by Joerg Battermann

2008-02-21T16:23:46Z

Thanks! Solved my problem with nil != ”” for strings as mentioned here: http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/145fcc2701653186/8d5b8acdf688e681#8d5b8acdf688e681

Comment on 'Validations on empty (not nil) attributes' by Marcello Golfieri

2008-02-01T16:56:32Z

How about prepending ”^$|” to the regexp?

Comment on 'Validations on empty (not nil) attributes' by Kai Krakow

2007-08-23T13:23:18Z

Brandon,

[quote] What is your intention of defining the type column as “NOT NULL” (forcing that column to have a value) if, without this plugin, there is absolutely no way to create a record through Rails with the type column being set to NULL? Seems like you could just remove that constraint. [/quote]

Well Rails allows to create records with this constraint active by the way it just sets the column to empty string. Of course this is suppressed by your plugin. But you are right: This constraint wasn’t optimal, it was just the default of the software I used to create this column. ;-)

Comment on 'Validations on empty (not nil) attributes' by Brandon

2007-08-19T14:51:12Z

Kai,

It look’s like Rails does not use the name of the base class for the type columns but instead an empty string which was set to nil by your plugin.

What is your intention of defining the type column as “NOT NULL” (forcing that column to have a value) if, without this plugin, there is absolutely no way to create a record through Rails with the type column being set to NULL? Seems like you could just remove that constraint.

I think the real power in this plugin is on validating uniqueness and not what your original intend was (validates_format_of).

The intent of this plugin is that I don’t want empty values spread all over my database. In 99% of cases, I don’t care about empty values and want them treated as null. In the other 1%, I don’t use this plugin and copy the code out of it to customize it. It’s only a couple lines

Comment on 'Validations on empty (not nil) attributes' by Kai Krakow

2007-08-19T10:16:40Z

Brandon,

My type column was defined “NOT NULL” but was set to null if I stored the base class in the table. It look’s like Rails does not use the name of the base class for the type columns but instead an empty string which was set to nil by your plugin. Would it be possible to extend the plugin to only touch fields that Rails validates_uniqueness_of? I think the real power in this plugin is on validating uniqueness and not what your original intend was (validates_format_of).

Comment on 'Validations on empty (not nil) attributes' by Brandon

2007-08-17T15:14:08Z

Kai,

I’m not sure that I follow you. I’m using the plugin in several projects that use STI.

Comment on 'Validations on empty (not nil) attributes' by Kai

2007-08-11T09:29:51Z

Very nice work. I solved the very same problem with validates_uniqueness_of …, :allow_nil => true with this. But I at once ran in to another problem: I am using this validation on a set of single inheritance tables. One can no longer use the “master” class with your plugin because the type column is set nil instead of empty. Your plugin should be enhanced to not touch the type column.

Comment on 'Validations on empty (not nil) attributes' by Eldon

2007-02-13T06:57:38Z

Just came across your posting and actually i think the problem is that you’re trying to use the allow_nil option on a method that it’s not designed to go with.

Check the API and you’ll see that there’s not an allow_nil option for the validates_format_of method.

In fact the only reason it doesn’t throw an error is because internally validates_format_of also calls the validates_each method which DOES have the allow_nil option but that’s still an incorrect use of the method.

I solved the same problem a while back by doing it like this.

I added a validates format on multiple optional SSN fields on a page like this: validates_format_of :byr1ssn1,:byr1ssn2,:slr1ssn1, :slr1ssn2, :with => /(^{?(\d{2})[\s.]?(\d{4})$)|}$/, :message => ‘Not Recognized as a Valid SSN’

This allows the end user to input anything that looks like a SSN and I accept it (i.e. they can format it any way that’s convenient for them – spaces, dashes, etc). If they leave this blank – no errors are thrown.

Then since I want all SSN’s in my database to be in a specific format – i added a before save method

before_save :convert_ssns

which just does this

def convert_ssns
  regex  = /^(\d{3})[\s.]?(\d{2})[\s.]?(\d{4})$/
  ssns = :byr1ssn1,:byr1ssn2,:slr1ssn1, :slr1ssn2
  for ssn in ssns
    r =  regex.match(self[ssn])
    if r
      self[ssn] = "#{r[1]}#{r[2]}#{r[3]}" 
    end  
  end
end

So I get the best of all worlds – an optional SSN field, easier input for end-users, and a consistent standard for the data in the database. And yeah looking at that convert_ssns method now – I can see that I should probably go back and refactor it a little as it’s a bit verbose.

Comment on 'Validations on empty (not nil) attributes' by Justin

2007-02-08T03:49:06Z

It does make sense in a round-a-bout kind of way – if you don’t specify the default value to be null, then both the database and rails are expecting a string, even if it is an empty one.

Whether Rails picks up on this or not is another questions, I’m not currently somewhere I can test this out. I had a similar problem with strings and nil previously, and it’s what somebody mentioned in #rubyonrails.

Comment on 'Validations on empty (not nil) attributes' by Justin

2007-02-08T03:42:24Z

II’m not 100% sure, but I believe you may be able to fix this in your schema. I think if you set the default value of the DB field to null, then rails will typecast empty entries to nil as expected.

Not 100% sure though, worth a try.

Comment on 'Validations on empty (not nil) attributes' by Brandon

2007-02-07T14:54:47Z

You’re right, the plugin is not entirely neccesary. However, I think it is a better solution.

ActiveRecord performs very transparent type-casting. Dates that come in as strings get automatically cast to Date; numbers get cast to Numeric. In my opinion, empty strings should get cast to nil.

I can’t think of a use-case where I would want to store and use and empty string value.

Comment on 'Validations on empty (not nil) attributes' by K. Adam Christensen

2007-02-07T13:35:22Z

Excuse my rudeness with the first comment.

Your plugin does make sense because there is the parameter :allow_nil to use. This certainly allows for that usage in the context of what you have.

That aside, I don’t know if that is important to warrant the use of this plugin. The example I gave performs the check in the context of what you were after.

What if your first form does not contain your social security number? Then certainly the :allow_nil option makes sense because there will not be an empty form field to pollute. Now say you have another form, which does ask for the social security number. Now your validation will fire off. The :allow_nil can almost be seen as “validate this when I ask for it”.

Comment on 'Validations on empty (not nil) attributes' by K. Adam Christensen

2007-02-07T12:55:21Z

The other thing you could have done was:


class Person < ActiveRecord::Base
  validates_format_of :social_security_number,
    :with => /\d{3}[-]?\d{2}[-]?\d{4}/, :if => :social_security_number?
end