I think it would be worth considering whether the API is really too strict. 
If someone is working with a model where completed must be either true or 
false, then why would they want to explicitly pass nil? In my experience, 
that usually happens when there is a bug. (Perhaps a deserialization or 
mapping method that doesn't properly set that attribute.) It may be 
beneficial to have the the API fail rather than silently accept that 
completed is false.

On Monday, March 24, 2014 1:49:43 PM UTC-7, James Miller wrote:
>
> Hi Everyone,
>
> Wanted to get some feedback on how you all implement something seemingly 
> trivial in your Rails apps, validation of boolean fields.
>
> Let's say you have a "completed" column in a table of tasks where it 
> should always be 0 or 1 in the DB (MySQL):
> add_column :tasks, :completed, :boolean, default: false, nil: false
>
> If you do nothing else and create a new record, omitting the "completed" 
> attribute it will create the record and set that attribute to false, 
> groovy. Explicitly set it to true, that'll work as expected too.
>
> But, if you explicitly set it to nil and save, MySQL adapter is going to 
> choke on it because the field isn't allowed to be null.
>
> So I can add this to the model:
> validates_inclusion_of :completed, in: [true, false]
>
> Now we're validating in the model, but the API seems a little too strict 
> to me -- if someone passes nil, validation fails -- part of me thinks it 
> should set it to true if explicitly true, else false -- overriding the 
> writer with something like:
>
> def completed=(completed)
>   write_attribute(:completed, completed == true)
> end
>
> Just seems like a lot of work for a simple boolean and wanted to see how 
> you all approach it.
>
> Happy Monday!
>
> James
>
>
>

-- 
-- 
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby
--- 
You received this message because you are subscribed to the Google Groups "SD 
Ruby" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to