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@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
