[Dbix-class] has_one joining through another table

[Steve Francia]

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 =3D> 'Takkle::Schema::UserPicture', { 'f=
oreign.user_picture_id' =3D> 'self.fk_user_picture_id' }, { proxy =3D> [ qw=
/owner/], } );


in user_picture:

__PACKAGE__->has_one(owner =3D> 'Takkle::Schema::User', { 'foreign.user_id'=
 =3D> 'self.fk_user_id' } );


and in my search:

    my $rs =3D $self->search(
            undef,
            {
            join =3D> [qw/ user_video/ ],
            prefetch =3D> [qw/ user_video/ ],
            cache =3D> 1,
            rows =3D> 9,
            }
        );


-Steve

Matt S Trout wrote:
> On Wed, Jun 27, 2007 at 10:32:29AM -0500, Wade.Stuart at fallon.com 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 sugges=
ted
> 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)
steve at takkle.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20070627/579=
bc54e/attachment-0001.htm