[Nitro] Unintuitive Og modeling

[Brian Davis]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: many_to_many.rb
Type: application/x-ruby
Size: 2198 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070309/edd1cab6/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: many_to_many-spec.bndl
Type: application/octet-stream
Size: 32548 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/nitro-general/attachments/20070309/edd1cab6/attachment-0001.obj