Hi guys, I saw this blog post on the Ruby Weekly mailing list and thought about your discussion. Briefly, it recommends that you use after_intialize to set default values with a small caveat. My personal thoughts are this would be a little robust than using before_validation.
http://www.easyactiverecord.com/blog/2014/03/25/creating-default-rails-active-record-model-attribute-values El mar 25, 2014 12:03 PM, "James Miller" <[email protected]> escribió: > Bill, > > In this case it was our client iOS app that was not properly mapping the > nil to the boolean when sending over the JSON payload. The app is in the > App Store, so waiting on approval and everyone to update is what made me > think that the API was too strict, though granted it was a bug in the > client. > > Thanks for your feedback everyone, much appreciated! > > James > > > On Mon, Mar 24, 2014 at 11:13 PM, Bill Vieux <[email protected]>wrote: > >> 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. >> > > -- > -- > 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. > -- -- 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.
