Koz, thanks for the explanation. The possibility that class attributes are the wrong solution had occurred to me, but that is the way things are currently done in ActiveResource.
A possible API change which avoids having to pass the values to every AR call (pretty awkward) would be to instantiate an object which holds the configuration data: @configured_resource = Resource.configure do |r| r.user = 'user' r.password = 'pass' end @configured_resource.find(1) # passes user and password That seems like a better design, even though it wouldn't match the ActiveRecord syntax. Thoughts? Nick On Mon, Nov 14, 2011 at 4:46 PM, Michael Koziarski <[email protected]>wrote: > > > On Tuesday, 15 November 2011 at 8:06 AM, Nick Urban wrote: > > My concern is that I don't want one thread to change the user and > password, and suddenly another thread has the wrong credentials set. > Is that a non-issue? > > It's a real issue, using class_attribute is *not* suitable for things > which are changed by multiple threads. > > > Any comment on resetting the value at the beginning of a request? > > To me it seems that this is only needed because the particular value > you're changing shouldn't be a class_attribute. Class attributes are great > simple solution for things like "what's the asset path" or "where is the > temp directory", but they're really just glorified global variables. If > you're flipping them every request then I'd suggest we should fix the > particular value to be something thread local or to have a completely > different API rather than try to put a band-aid on the whole notion of > class attributes. > > -- > Cheers, > > Koz > > > > On Nov 14, 3:31 pm, Yehuda Katz <[email protected]> wrote: > > class_attribute works by creating a method on the class, and creating > methods should be reliable. > > Additionally, class_attributes are used for configuration during boot, > which is not a threadsafe environment. > > Yehuda Katz > (ph) 718.877.1325 > > > > > > > > On Mon, Nov 14, 2011 at 10:19 AM, Nick Urban <[email protected]> wrote: > > I want to be able to set class attributes (in particular, > ActiveResource::Base user, password, site, etc.) and for them to be > isolated to a given request, both in terms of thread safety, and so > that for the next request they are reset to defaults. For instance, if > I set user and password, I want to make sure the user and password set > for one user do not accidentally get used for a different user on a > subsequent request. I could do this with a before_filter, but that > seems like the wrong place to manage a model class' instance > variables. > > > I'm not sure if the threading issue is really a problem, because I > understand most rails servers are single threaded, but would it be a > good idea to use Thread.current in class_attribute to provide thread > safety? > > > Secondly, what do you think of providing a way of resetting the value > of class attributes between requests? > > > Perhaps: > > > class_attribute :x, :default => 'x will have this value at the > beginning of every request' > > > or > > > class_attribute :x > class_initializer :set_x > def self.set_x > # this gets run at the beginning of every request > self.x = 'Initial value' > end > > > ActiveResource::Base.user doesn't actually seem to be using > class_attribute right now, but I assume it could be updated to do so. > > > Please correct me if I have misunderstood the issues. > > > Thanks, > > > Nick > > > -- > 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. > > > -- > 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. > > > -- > 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. > -- 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.
