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 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 noticable performance hit is incurred. Perhaps then my nightmare with this code section will end. Thanks - cheers! -- Jeff ----- Original Message ----- From: Jonathan Viney <[EMAIL PROTECTED]> To: rails-core@lists.rubyonrails.org Sent: Tuesday, May 9, 2006 8:12:13 PM GMT-0600 Subject: Re: [Rails-core] Issue in ActiveRecord generated reader methods 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 attribute is present and raises an exception if it's not. You'd probably want to leave that check in there. Why don't you make a patch and see if it breaks anything :) -Jonathan. On 5/10/06, Jeff Hall <[EMAIL PROTECTED]> 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 (influenced by the > ModelSecurity generator). Shortly after implementing some code to > check this behavior, I began to see undefined behavior from rails. > The first request to read an attribute would be denied correctly, > however further requests would proceed without fail. > > After a lot of searching, I think I have traced the problem down to > the generated read methods. When > ActiveRecord::Base#generate_read_methods is false, all is well. When > its true, my migraine returns. > > More research, reading, and I come to this curiosity... > > 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 read_attribute... instead it accesses the > attribute directly and performs a type cast (if necessary) > > Is this intended? Am I missing something that read_attribute is > doing that is not appropriate for a defined attribute reader method? > > It's near trivial to draft a patch for this - however, I wanted to > make sure I wasn't vastly underestimating something. > Comments? > > Thanks everyone! > -- > Jeff Hall > Technology Consultant > Digital Maelstrom > > Email: [EMAIL PROTECTED] > Jabber/XMPP: [EMAIL PROTECTED] > > _______________________________________________ > 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 -- Jeff Hall Technology Consultant Digital Maelstrom Email: [EMAIL PROTECTED] Jabber/XMPP: [EMAIL PROTECTED] _______________________________________________ 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
