> > 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. I just checked this out with 100.000 user/friendship entries and the view is slow as hell :( Although this is in fact the cleanest solution I've seen up until now it's also the slowest. The main problem is: I have to make a somewhat complex union query on the friendship-table which should then automagically resolve the resulting user_ids into User objects. Maybe there's some DBIx::Class magic that allows me to run a custom query on another Class (UserFriendship, with $self->id() as a where condition) and returning objects of the current class (User). --Tobias _______________________________________________ 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/
