[Dbix-class] Listing of many_to_many relations (ResultSet reflection)

[Zbigniew Lukasiak]

Hi Matt,

No need for heating the debate.  I feel now we are at least getting
into something.  I would like to validate the API first before I go
into the details about the needed data structures.  Otherwise I would
have to think up all possible data structures supporting all possible
APIs - it is more economic to first narrow the search space.

I can accept that you don't want to have the bridge relations listed
by the relationships method. You did not really answered my argument
that "If it walks like a duck and quacks like a duck ..." and about
hiding low level details  (which should be good for high level
interfaces).  But I can understand that it might be difficult or
something and that generally you decide. OK.

But then the only other way to have the reflection I can see is to add
another method - this is what I wanted to validate before I start
looking into the needed datastructures.  It does not matter at this
moment if it is called many_to_many_relationships or
bridge_relationships or any other name, but rather just that we choose
to add another method.

Cheers,
Zbyszek

On 1/31/07, Matt S Trout <dbix-class at trout.me.uk> wrote:
>
> On 31 Jan 2007, at 10:44, Zbigniew Lukasiak wrote:
>
> >>
> >> Neither of these are acceptable; please review the IRC logs where I
> >> explained the design constraints involved.
> >
> > I can only see you mentioned Moose as the future basis of DBIC.  I
> > need to admit I don't see how this is in contradiction with any of
> > those proposals - even if I do see that when we have Moose then
> > perhaps neither is needed any more.
> > I can also see that you say that many_to_many are not real relations -
> > I covered that point in my email.
>
> Actually, I said that many-many is a bridge across two relationships
> and that we needed to cover the general case of that in terms of the
> result_source level infrastructure, including providing metadata.
>
> What I was expecting was a proposal of how to handle that and what
> metadata would be required, plus how it would work in with the
> current implementation.
>
> Instead, you sent a message suggesting two options I'd already told
> you weren't of any use (it's NOT A RELATIONSHIP so your option 1 is
> clearly useless as I've had to tell you every single time we've
> discussed this, and it's a general case of relationship bridges so
> clearly many_to_many_relationships as a one-off hack is just as stupid).
>
> RFC when you've actually sat down and thought about it, please.
> --
> Matt S Trout, Technical Director, Shadowcat Systems Ltd.
> Offering custom development, consultancy and support contracts for
> Catalyst,
> DBIx::Class and BAST. Contact mst (at) shadowcatsystems.co.uk for
> details.
> + Help us build a better perl ORM: http://dbix-
> class.shadowcatsystems.co.uk/ +
>
>
>
> _______________________________________________
> List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> Wiki: http://dbix-class.shadowcatsystems.co.uk/
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
> Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/
>


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/