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 <[EMAIL PROTECTED]> 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/[email protected]/



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

_______________________________________________
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/[email protected]/

Reply via email to