On 4/25/07, Tobias Kremer <[EMAIL PROTECTED]> wrote:
Am 25.04.2007 um 23:10 schrieb Brandon Black:
> On 4/25/07, Tobias Kremer <[EMAIL PROTECTED]> wrote:
>> Sounds like my kind of problem - what are the alternatives to proxy?
>
> One alternative to proxy is just to not use proxy. Proxy is merely
> convenience. Instead of saying $user_relation_object->username (which
> is ambiguous given your duplicate proxy statements), say
> $user_relation_object->requestor->username or
> $user_relation_object->receiver->username.
Yeah, but that's exactly what I want to avoid. If somebody does
$user->confirmed_friendships, he/she is not supposed to know who
initiated the friendship (requestor or receiver). All he/she wants
is a list of User objects (except $user) which are friends of $user.
The same goes for the other two methods. Currently I can't see a
sane way to accomplish this with DBIx::Class :(
Follow the advice from the other thread (make a view that unions the
table with itself, if possible use insert/update triggers to re-order
the two generic user columns in a consistent manner (and if doing
that, then add a third field for who initiated it)), and then add that
view to your schema with a relationship to user so that you can query
it.
-- Brandon
_______________________________________________
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/
