> The key here is that they do behave as expected in production. There > is nothing inherently wrong about keeping instances between requests. > It works, and it works well, just not with the odd behaviour unique to > AR.
This will not affect production users unless you have cache_classes off. If you do your performance will be awful as all these constants get removed and redefined every request. Is there a reason you have cache_classes set like that? > > The same reload behaviour described in previous posts effects any > constant defined via a require_dependancy. It is only the deletion of > methods and class attributes on AR instances that I am questioning, > and that is all this patch addresses. I commented on the ticket but will do so here for completeness. The behaviour in question was added to fix a memory leak caused (I believe) by ruby not GCing procs passed to define_method when the constant was garbage collected. As such we can only apply this patch if all 'popular' versions of ruby no longer hold on to those procs. If they still leak, then this is really just a bitter side effect of our having to work around a ruby bug. > If this is indeed the aim, should the same logic apply to instances of > other classes? > > I fear this is a bridge too far. As this was only done to support a particular memory leak due to a particular ruby bug. If it's still a problem we can look at an alternative fix in 2.3, however the memory leak in dev mode was pretty severe and very very annoying. -- Cheers, Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
