findchris, I'm a bit reluctant to put my patch up for serious consideration because it currently lacks tests and would rightfully get slapped down pretty quickly.
Care to try your hand at writing the tests? I'd be willing to patchify my solution sometime in the next two or three weeks if that would help. Anybody on core care to comment on the state of AR for accepting a patch like this? -Chris On Jun 14, 9:32 pm, findchris <findch...@gmail.com> wrote: > You might try updating the lighthouse ticket with this patch to try to > drum up support. Seems quite useful. > > +1 > > On Apr 22, 8:39 am, Chris Cruft <c...@hapgoods.com> wrote: > > > I've expanded my monkey patch (see it here:http://gist.github.com/88448) > > to the point where I wouldn't call it proof of concept anymore. It > > works very nicely in practice as well. The concept of scoped > > associations and composing of scopes, regardless of my implementation, > > seems strong. Luke, I would love your thoughts on this approach since > > it's pretty close to your original syntax. > > > The implementation has two major flaws/shortcomings: > > > 1. No tests > > 2. No proper patch (trivial) > > 3. No support for procedural scopes (important, IMO) > > > Anybody care to take a stab? > > > On Mar 31, 6:37 pm, Chris Cruft <c...@hapgoods.com> wrote: > > > > And here is the monkey patch for getting scoped join models (and > > > targets): > > > > http://gist.github.com/88448 > > > > This is a "proof of concept" patch. It only scopes has_many > > > associations (and has_many/has_one :through => <has_many> > > > indirectly). Scoping has_one should be a trivial matter of > > > adding :scope as a valid option. I don't think belongs_to would be > > > hard either. HABTM, as usual, is a _special_ case and would probably > > > explode on lift-off. > > > > The second limitation is that "procedural" scopes (those that take > > > parameters) are not supported. I could not think of a clean syntax to > > > deal with the > > > parameters and I wasn't (yet) prepared to support a proc/lambda as the > > > param. As a side note, the chicken-and-egg problem of specifying > > > association by having each end refer to the other frustrates clean > > > syntax... > > > > -Chris > > > > On Mar 31, 12:24 pm, Chris Cruft <c...@hapgoods.com> wrote: > > > > > The named_scope macro introduces a concise syntax for a complex set of > > > > [:order, :conditions, :joins, :include, :offset, :limit, :readonly] > > > > options for a model class. The options for the association macros use > > > > most of those SAME OPTIONS. My first suggestion is that association > > > > macros accept a :scope option, which is a symbol naming a named_scope: > > > > > Replace this: > > > > has_many :important_taggings, :class_name => > > > > 'Tagging', :conditions => {:flag => :important} > > > > With this: > > > > has_many :important_taggings, :class_name => 'Tagging', :scope > > > > => :important > > > > > where the 'important' scope exists on the Tagging model as in Luke's > > > > example. The scope option could also be used to replace many of the > > > > other SQL-related options (e.g. :order, :include, :limit). And > > > > eventually the scope could be extended to include a lambda for dynamic > > > > construction of a scope. The essence of this suggestion is > > > > that :scope can be used to simplify the options for association macros > > > > AND introduce new, regular behavior (see below). > > > > > Like Luke's original proposal, I'm suggesting that the macros accept > > > > a :scope option. Unlike Luke, I am suggesting that, in the presence > > > > of the :through option the :scope option NOT be treated as a special > > > > case -let it scope the target, NOT the join model. So in this > > > > example: > > > > > has_many :important_tags, :through => :important_taggings, :source > > > > => :tag, :scope => :g_rated > > > > > the :g_rated scope is NOT coming from the JOIN table (Taggings) but > > > > rather the target (Tags). > > > > > The best news is that a trivial patch achieves this functionality AND > > > > it provides the stupendously wonderful feature of scoping the creation > > > > of join models. Following my example above: > > > > > user.important_tags.create > > > > > will create a Tag within the :g_rated scope AND create a Tagging > > > > within the :important scope (:flag => 'important' to use Luke's > > > > model.) No more extensions required to accomplish the obvious and > > > > trivial setting of the :flag attribute. > > > > > Here is the patch against 2.2.2:http://gist.github.com/88236 > > > > > I'll post a monkey patch as well. > > > > > One last comment: I started out liking Ryan's syntax. But I lost my > > > > enthusiasm when I realized that the target class would need to be > > > > decorated with a named_scope for each of the paths that associated > > > > with it. It just doesn't seem like good encapsulation. In the > > > > example, is it right that the Tag model need to know about the Tagging > > > > class' scopes? In this example, it's a bit awkward. But in other use > > > > cases, I think the target class will get pretty ugly with scopes > > > > referring to the myriad ways in which it might be associated. And for > > > > the case of a utility model provided by a plugin, the decoration of > > > > the target is relatively expensive. > > > > > On Feb 27, 1:37 pm, Luke Redpath <ljredp...@gmail.com> wrote: > > > > > > In my current project, I have an association model that has various > > > > > flags available. To keep the implementation of these flags > > > > > encapsulated, I created named_scopes for each flag and use these > > > > > scopes for finding and creating. > > > > > > This model sits between two others as the join model in a > > > > > has_many :through association. I actually wanted various > > > > > has_many :through associations that use the same join model but > > > > > different scopes. Unfortunately has_many :through doesn't have > > > > > a :scope option; I could use :conditions to get it working but I've > > > > > now broken the encapsulation I aimed for when I introduced the named > > > > > scopes and created unnecessary duplication. > > > > > > Hopefully this rather contrived example should make it clear what I'm > > > > > aiming for. > > > > > >http://gist.github.com/71585 > > > > > > And my initial implementation, currently in use in our app (tries to > > > > > extend ActiveRecord in the least-intrusive way): > > > > > >https://gist.github.com/9d7f86e27014ef5df280 > > > > > > And now, my attempt to do it properly as a patch to ActiveRecord, with > > > > > a test. > > > > > >http://gist.github.com/71587 > > > > > > I don't expect this patch to be completely ready for inclusion; there > > > > > are probably other things to consider such as, do you just want to > > > > > pull the :conditions from the proxy? Is there anything else to pull > > > > > in? Could this be written in a better way (probably, my knowledge if > > > > > the AR internals is slim). > > > > > > Any thoughts? > > --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
