A shortcoming of this solution is that you'd have to perform the configuration for all active resource classes that you're using, which would significantly reduce its 'dryness'. Given the current ARes design, having an inheritable configuration is very valuable. Perhaps a better solution would be to create a threadsafe, resettable class-attribute-like structure which could be mixed into ActiveResource::Base?
On Mon, Nov 14, 2011 at 5:20 PM, Nick Urban <[email protected]> wrote: > 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.
