[Nitro] Unintuitive Og modeling

[George Moschovitis]

Brian, thanks for your first patch ;-) I added this to the repo.
Hopefully someone can work on this and make this spec pass.

-g.

PS: there are still missing validations in the new implementation. It
is very easy to contribute here (just copy/update code from the old
files - still included in the repo, move everything to
og/validation.rb so we can get rid of glue/validation.rb)



On 3/10/07, Brian Davis <brian.william.davis at gmail.com> wrote:
> On Fri, 2 Mar 2007 10:57:58 +0200
> "George Moschovitis" <george.moschovitis at gmail.com> wrote:
>
> > I think your suggested solution is reasonable. A problem is that it is
> > backwards incompatible but I prefer something that works. I am
> > wondering if Jonathan or Judson could provide a patch for this (as I
> > am working on Nitro stuff at the moment).
> >
> > thanks,
> > George.
> >
> >
> > On 3/2/07, Brian Davis <brian.william.davis at gmail.com> wrote:
> > > NOTE: I posted this at the Google Groups interface, but my message
> > > has languished in the ether.
> > >
> > > I spoke with Kashia earlier about this and he encouraged me to post
> > > this to the mailing list.
> > >
> > > Consider the following model definition:
> > > --------------------
> > >   class User
> > >     ...
> > >     many_to_many :buddies, User, :foreign_name => :buddies
> > >     many_to_many :buddies_pending_confirmation, User, :foreign_name
> > > => :buddies_requested
> > >     many_to_many :buddies_requested, User, :foreign_name
> > > => :buddies_pending_confirmation
> > >     ...
> > >   end
> > > --------------------
> > >
> > > This is a reflexive join with several distinct relationships that
> > > happen to join to objects of the same class. My issue is that, with
> > > Og, only one join table is created to model *all* of these
> > > relationship: og_user_user. Because of this, the relationships are
> > > essentially mirrored. Thus, if a user is added to my
> > > 'buddies_pending_confirmation' queue, they also appear in my
> > > 'buddies' and 'buddies_requested' lists, although this is precisely
> > > the opposite of the intended behavior.
> > >
> > > Kashia showed me a hack that circumvents this behavior (by defining
> > > a self-join class for each of the relationships above), but we both
> > > found it to be, well, a hack. It lacked the clarity and
> > > intuitiveness of the code above.
> > >
> > > My suggestion, then, is to perhaps name join tables not by their
> > > associated types, but by their given label (the first argument to
> > > 'many_to_many'). Thus, my 'og_user_user' table right now would
> > > actually be three tables, 'og_user_buddies',
> > > 'og_user_buddies_pending_confirmation' and
> > > 'og_user_buddies_requested'.
> > >
> > > Please let me know if this is unreasonable, stupid or unclear. Also,
> > > if there's something I'm just altogether missing, set me straight.
> > >
> > > Thanks,
> > >
> > > Brian
> > > _______________________________________________
> > > Nitro-general mailing list
> > > Nitro-general at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/nitro-general
> > >
> >
> >
>
> Attached is a bundle I threw together during my lunch break. Please
> excuse me, as I'm new with Darcs and couldn't test the spec myself (I
> get a number of errors about the spec being unable to locate 'glue').
> If this is inappropriate or unnecessary, please let me know. If nothing
> else, hopefully this will serve to demonstrate the issue I've been
> having with Og relations and how my proposed fix could help remedy
> things.
>
> Also attached is the spec itself, in case I muddled the Darcs
> procedure.
>
> Regards,
>
> Brian
>
> --
> Brian Davis
>
> Project Manager
> FreezeCrowd, Inc.
>
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general
>
>


-- 
http://blog.gmosx.com
http://cull.gr
http://www.joy.gr
http://nitroproject.org