This is sort of off topic but it arose from a cucumber test failure and I am unsure how to address the underlying issue. I spent yesterday tracking down an obscure error that was exposed by a new cucumber test. It turned out to be an improper default value assignment made in a controller which in turn proved dependent upon recent changes (Rails 2.2) made in how AR handles timezones. It also turned out that the same error was made in another controller handling that same model. This led me to consider that the place to handle AR default values really should be somewhere else and the logical places are either in the model or in the DBMS schema. The problem with the latter is that Rails migrations provide no accommodation for dynamic defaults like the current time, other than by recourse to explicit SQL. In any case, a DBMS provided default value is not going to be available to a view until after the new row is INSERTed and subsequently SELECTEed, which is too late to be of any use in the presentation of a "new"/"create" resource pair. Thus, I considered it best to handle this requirement in the model. There is a vast amount of information on this subject but it appears, to me, inconsistent and the issue unresolved. The obvious answer is to override the initializer method. However, there are several warnings that basically say that for AR this is NOT A GOOD IDEA! There are a few references that indicate AR may not actually call #new in every case. There is also the matter of interpretation of what new actually means to an ORM. A new model instance is not always the same thing as a new DBMS "row". There are references to using the :after_initialize callback. However, after_initialize is called on every row instantiation whereas a default value only applies on a new DBMS instance. This is an old topic for the rails core team: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/b509a2fe2b62ac5 So, after confusing myself thoroughly, I have to ask: How do people here handle dynamic default values? Do leave these instructions in the controllers or is there an accepted technique for moving this code into the model? If there is then what is it? I ran across this in my research: http://m.onkey.org/2007/7/24/how-to-set-default-values-in-your-model But this is not what one would describe as self documenting code. -- Posted via http://www.ruby-forum.com/.
On Mar 4, 2009, at 12:16 PM, James Byrne wrote:> This is sort of off topic but it arose from a cucumber test failure > and > I am unsure how to address the underlying issue. > > I spent yesterday tracking down an obscure error that was exposed by a > new cucumber test. It turned out to be an improper default value > assignment made in a controller which in turn proved dependent upon > recent changes (Rails 2.2) made in how AR handles timezones. It also > turned out that the same error was made in another controller handling > that same model. > > This led me to consider that the place to handle AR default values > really should be somewhere else and the logical places are either in > the > model or in the DBMS schema. The problem with the latter is that > Rails > migrations provide no accommodation for dynamic defaults like the > current time, other than by recourse to explicit SQL. In any case, a > DBMS provided default value is not going to be available to a view > until > after the new row is INSERTed and subsequently SELECTEed, which is too > late to be of any use in the presentation of a "new"/"create" resource > pair. > > Thus, I considered it best to handle this requirement in the model. > There is a vast amount of information on this subject but it > appears, to > me, inconsistent and the issue unresolved. The obvious answer is to > override the initializer method. However, there are several warnings > that basically say that for AR this is NOT A GOOD IDEA! There are a > few > references that indicate AR may not actually call #new in every case. > There is also the matter of interpretation of what new actually > means to > an ORM. A new model instance is not always the same thing as a new > DBMS > "row". > > There are references to using the :after_initialize callback. > However, > after_initialize is called on every row instantiation whereas a > default > value only applies on a new DBMS instance. This is an old topic for > the > rails core team: > > http://groups.google.com/group/rubyonrails-core/browse_thread/thread/b509a2fe2b62ac5 > > So, after confusing myself thoroughly, I have to ask: How do people > here > handle dynamic default values? Do leave these instructions in the > controllers or is there an accepted technique for moving this code > into > the model? If there is then what is it? I ran across this in my > research: > > http://m.onkey.org/2007/7/24/how-to-set-default-values-in-your-model > > But this is not what one would describe as self documenting code.You could try this plugin: http://github.com/aussiegeek/active_record_defaults/tree/master Scott> > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
Scott Taylor wrote:> You could try this plugin: > > http://github.com/aussiegeek/active_record_defaults/tree/master > > ScottThanks, I will try this out. -- Posted via http://www.ruby-forum.com/.
On Wed, Mar 4, 2009 at 2:58 PM, James Byrne <lists at ruby-forum.com> wrote:> Scott Taylor wrote: > >> You could try this plugin: >> >> http://github.com/aussiegeek/active_record_defaults/tree/master >> >> Scott > > Thanks, I will try this out.Hi James. Just a quick message to let you know that I''ve used active_record_defaults in the past, and it''s been very helpful. Good luck. -Nick
Not sure if this is what you''re looking for, but there is also this: http://github.com/FooBarWidget/default_value_for/tree/master On Wed, Mar 4, 2009 at 1:58 PM, James Byrne <lists at ruby-forum.com> wrote:> Scott Taylor wrote: > > > You could try this plugin: > > > > http://github.com/aussiegeek/active_record_defaults/tree/master > > > > Scott > > Thanks, I will try this out. > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20090305/820d7b18/attachment.html>