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 than looking up @attributes directly. Line 1825 of base.rb changes from if !(value = @attributes[attr_name]).nil? to: if !(value = read_attribute_before_type_cast(attr_name)).nil? And similarly the generated reader to use read_attribute_before_type_cast instead of @attributes. That way you can simply override read_attribute_before_type_cast and it will affect both read_attribute and the generated read_methods. Thoughts? -Jonathan On 5/10/06, Jeremy Kemper <[EMAIL PROTECTED]> wrote:
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 each attribute's column type is faster than does-it-all read_attribute. It's for performance alone: you may disable generated readers with no loss of functionality (though you may consider generating your own..) jeremy _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
_______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
