On Wed, March 30, 2011 17:06, Frederick Cheung wrote: > > Well I certainly consider it desirable to read the defaults from the > database. I'd consider it extremely unintuitive if a validation > failed because some column was not set even though the default > value for the column would have made that validation pass. >
Explicitly setting column values when they are not referenced in the code and have valid defaults on the DBMS is fairly unintuitive as well. In the validations case, one always has the option to provide ones own default in the model. In this case one has no way to avoid the consequences of AR's behaviour. At the very least there should be some way to limit AR's default setting action to certain columns or tables; or to exclude specific columns and tables from this treatment. > Now it would probably be nice if rails spotted that values unchanged > from the defaults were in that state and so didn't try and set them > explicitly (and I vaguely remember that being mentioned a long, long > time ago), but that would require more code, not less. > Rails evidently does spot it: instance#attribute_present?( :attribute ). It just does not use that information when constructing the INSERT query. -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
