Hi All,
Because of Josh Susser's post a while back about "ganging up on tests
and docs" I figured it would be a good idea to start creating
documentation for parts of Rails I found without documentation.
http://dev.rubyonrails.org/ticket/5013
Can someone apply the patch?
Manfred
_
Manfred,
In the future, please add the 'docs' keyword to documentation patches,
it helps us get them processed more quickly. Thanks for the patch.
Kev
On 5/9/06, Manfred Stienstra <[EMAIL PROTECTED]> wrote:
Hi All,
Because of Josh Susser's post a while back about "ganging up on tests
and docs"
Hi all !
I am adding observers to some model objects. One of these uses
RailsCron. RailsCron adds a class method to ActiveRecord::Base.
Unfortunately, during the initialization phase, plugins aren't yet
loaded, so I can't setup my observers in config/environment.rb, as
suggested by the commen
Hi all!
I have come into a strange issue in Rails that I am hoping someone
can shed some light.
To make a very long story short, I have been researching how to
override ActiveRecord::Base#read_attribute and write_attribute to
perform security checks at the model level (influenced by the
On Tue, May 09, 2006 at 07:41:41PM -0500, Jeff Hall wrote:
> ActiveRecord::Base#define_read_method(symbol, attr_name, column)
> generates reader code for an attribute after Rails realizes there
> should be a reader method for it, correct? But the generated reader
> method body does not call
I agree that seems odd. I can't see any reason not to use
read_attribute there, as it will type cast if necessary.
define_read_method could be simplified and Column#type_cast_code
should be unnecesary perhaps.
Currently, define_read_method uses @attributes.has_key? to verify that
the attribut
Jonathan,
Patch doesn't appear to break anything. All the unit tests run green.
However, Marcel suggested that Stefan implemented this method intentionally for
performance reasons. I will submit the patch as a Trac ticket - maybe then
someone more skilled at benchmarking than I can see if any
Sounds good. I can't see any obvious reason why the current
implementation would be a lot faster than simply using read_attribute.
I'll have a look at the ticket once you've posted it.
-Jonathan.
On 5/10/06, Jeffrey Hall <[EMAIL PROTECTED]> wrote:
Jonathan,
Patch doesn't appear to break anythi
On May 9, 2006, at 6:12 PM, Jonathan Viney wrote:
I agree that seems odd. I can't see any reason not to use
read_attribute there, as it will type cast if necessary.
define_read_method could be simplified and Column#type_cast_code
should be unnecesary perhaps.
Inline type casting tailored to
> Inline type casting tailored to each attribute's column type is
> faster than does-it-all read_attribute. It's for performance alone:
Jeremy,
This is a very good point. However, I am concerned about the origin of this
whole discussion.
Is it desirable that if the behavior of read_attribu
So it simply puts the type casting code into the definition of each
read method to avoid calling Column#type_cast_code each time the read
is called? How much difference does that really make?
Another solution to this may be to change read_attribute to use
read_attribute_before_type_cast rather th
> That way you can simply override read_attribute_before_type_cast
> and it will affect both read_attribute and the generated read_methods.
> Thoughts?
As I see it, the inconsistancy exists in one of two places. If typecasting as
performed by read_attribute really impacts performance undesirbl
Yeah, it is a bit inconsistant that the first call ends up executing
different code than a subsequent call. method_missing should probably
be changed to address this.
But, I don't think that will solve your original problem of needing to
be able to override the read methods ... ?
-Jonathan.
On
> But, I don't think that will solve your original problem of needing to
> be able to override the read methods ... ?
Haha - well as far as I can tell, my problem lies only in the fact that the two
calls are different. My code works on the first reader call and breaks on any
successive calls.
Jeff Hall wrote:
Hi all!
I have come into a strange issue in Rails that I am hoping someone can
shed some light.
To make a very long story short, I have been researching how to
override ActiveRecord::Base#read_attribute and write_attribute to
perform security checks at the model level (infl
For performance reasons, the generated read method does not use
read_attribute, so I doubt that it will be changed.
Changing both read_attribute and the generated read method to use
read_attribute_before_type_cast gives you a single point where you can
intercept all read methods and shouldn't hit
Thanks a bunch for all your input. If I have further issues, I'm sure that I
will come running back! :)
-- Jeff
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
17 matches
Mail list logo
