1

I realized when thinking about the user, password, and site variables in ActiveResource::Base, that they could be modified on one request and would remain modified on the next request. That seems like undesirable behavior, and possibly a widespread problem, since it applies to all use of class variables / attributes.

Does Rails provide a mechanism for cleaning up changes to class-level state (e.g. reset to default) so that each request starts in a pristine condition?

If not, would it be possible to add a way of initializing class variables which would get re-applied at the beginning of each request? This could be combined with thread-safe storage, making class variables much less problematic. A possible modification of class_attribute?

Update:

As I described in the linked question above, the specific case that brought this to my attention was the fact that I was setting ActiveResource::Base.user and password on a per-user basis. If I ever failed to reset them, that would mean that REST requests on behalf of one user would be made using the credentials of another on subsequent page loads.

Community
  • 1
  • 1
Nick Urban
  • 3,568
  • 2
  • 22
  • 36

1 Answers1

0

Just out of curiosity, can you give a concrete example of why you want to do this? On the face of it, it sounds like you're requesting a change to a variable, so Rails is doing what you're asking for.

As far as an answer, a few options:

  • There's no automatic "switch back to default" behavior for variables, no.
  • You could manually reset the values at the end of each controller action where you want this to happen
  • You could write a module that does this (called it, "acts_as_resettable"?), and then include that module in the classes where you want this functionality
jefflunt
  • 33,527
  • 7
  • 88
  • 126
  • It seems like extending class_attribute would be a good way to do this, because it already provides the behavior I want (inheritable class-level attributes). It could be passed a default value which it would save and reset on every request, and it could make use of Thread.current as @KandadaBoggu suggested in the other post in order to guarantee thread safety if that's an issue. – Nick Urban Nov 11 '11 at 23:08