On Tuesday, 15 November 2011 at 11:23 AM, Nick Urban wrote:
> 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? > The current design is, basically, just not really intended for the use case you have in mind. So there are two options, either completely rework ActiveResource's api such that it *does* work in this way, or accept its limitations and use one of the dozens of other http client libraries. I've had several clients who use ActiveResource as a nice simple integration API to tie one app to another, but others who had a more complicated authentication or connection management requirement. Those clients use other libraries and I don't think there's anything horribly wrong with that. -- Cheers, Koz > > > On Mon, Nov 14, 2011 at 5:20 PM, Nick Urban <[email protected] > (mailto:[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] > > (mailto:[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] (http://gmail.com)> > > > > 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 (tel:718.877.1325) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Nov 14, 2011 at 10:19 AM, Nick Urban <[email protected] > > > > > (http://gmail.com)> 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] > > > > > > (mailto:[email protected]). > > > > > > To unsubscribe from this group, send email to > > > > > > [email protected] > > > > > > (mailto:[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] > > > > (mailto:[email protected]). > > > > To unsubscribe from this group, send email to > > > > [email protected] > > > > (mailto:[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] > > > (mailto:[email protected]). > > > To unsubscribe from this group, send email to > > > [email protected] > > > (mailto:rubyonrails-core%[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] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[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.
