So, I continued to play with it and came up with the following, which is
quite similar to Matt's reply, but slightly different.
I am wondering if someone can advise me of which way is better and why?
I am thinking this approach is, since there is only one owner, it does
seem a bit off to use has_many, but I don't have enough experience with
DBIC, perhaps there is a giant hole in this approach.
in picture:
__PACKAGE__->has_one(picture_owner => 'Takkle::Schema::UserPicture', {
'foreign.user_picture_id' => 'self.fk_user_picture_id' }, { proxy => [
qw/owner/], } );
in user_picture:
__PACKAGE__->has_one(owner => 'Takkle::Schema::User', { 'foreign.user_id' =>
'self.fk_user_id' } );
and in my search:
my $rs = $self->search(
undef,
{
join => [qw/ user_video/ ],
prefetch => [qw/ user_video/ ],
cache => 1,
rows => 9,
}
);
-Steve
Matt S Trout wrote:
> On Wed, Jun 27, 2007 at 10:32:29AM -0500, [EMAIL PROTECTED] wrote:
>
>>>> Sadly, that is the way we had it, we decided to switch to using the
>>>> owner flag to try to eliminate duplication of data in the database.
>>>>
>>> False economy - that isn't duplication, as the first reply to the this
>>> post points out. Won't work the way you've got it, we don't tend to add
>>> code to make broken database layouts easier to core.
>>>
>> True, but what if you have properties about the relationship that reflect
>> the many to many map directly? ignore one-owner-per-picture, and suppose
>> you have a set of data such as preferences that are directly related to the
>> many-to-many relationship between user and picture. Is the mapping table
>> not the correct place for this data? Most of the database schemas I have
>> seen over the year would place this relationship modifying data in the
>> user_picture mapping tables. What is your view on this? make another
>> table that stores the preferences? Am I mistaken that this is pretty
>> "normal" database design?
>>
>
> I'd implement that with the has_many + prefetch + proxy approach I suggested
> in my original reply in this thread - which was based on the mistaken
> assumption that what the OP was doing was what you just described :)
>
>
--
Steve Francia
Lead Developer
Takkle, Inc.
212.792.5859 (fax)
[EMAIL PROTECTED]
_______________________________________________
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]/
