[Dbix-class] Detecting a "belongs_to" relationship.

[fREW Schmidt]

On Wed, Mar 24, 2010 at 12:55 AM, Rolf Schaufelberger <rs at plusw.de> wrote:
>
>>
>> >    my $artist =3D $cd->artist;  # hits the database again
>> >    my $artist_id =3D $artist->id;
>> >
>>
>> I define my relationships like that :
>>
>> belongs_to ( artist =3D> 'My::Schema::Artist','artist_id' );
>>
>> so
>> $cd->artist gives me the artist object
>> and
>> $cd->artist_id  gives me just the key.
>>
>
> Thanks, I've seen that recommendation before.  Of course, this is an
> existing database and the column is already just "artist" and it's
> impossible to rename the column.  (And I'm in the camp where I abhor FKs
> with the _id suffix.  Of course the FK is an id.)
>
> Sure, I could do this:
>
> sub artist_id {  return shift->get_column( 'artist' ) }
>
> but I was asking:
>
>
>> > What's an efficient way to detect the belongs_to relationship?
>>
>
> That is, have a method like:
>
> $item->is_belongs_to_relationship( $accessor )
>
> I'm not sure I'll use that approach, but it would be useful to have this
> available.
>
>
> Hum... The two accessor approach ($cd->artist and $cd->artist_id) has oft=
en
> made me wonder about the design of DBIC.
>
> I find it interesting that two powerful features of Class::DBI (there
> weren't many) didn't make it into DBIC by default.
>
> Lazy loading is one.  True, it can be expensive to create the objects
> before they are needed -- but much less expensive then going to the db wh=
en
> not needed.  Lazy loading in CDBI allowed creating empty objects and not
> fetching column data until actually needed.   That is, $cd->artist->id
> didn't need to go back to the database to find out something that is alre=
ady
> known.  It's has not been uncommon in our app to find in a template [%
> cd.artist.id %] in a loop which (unknowingly by the template coder)
> hammers the database.  It's a natural thing to write -- the coder didn't
> expect it to go to the db for something it already knows.
>
> Obviously, the other "feature" of lazy loading is if 99% of the time you
> need a small number of columns, but something in the View that other 1% of
> the time decides all columns are needed.
>
>   PROCESS show_user_profile;  # display basic data from $user object.
>   PROCESS show_extra_user_data IF user.is_administrator;
>
> Yes, one could argue that the Controller should determine this case and
> include extra columns.  But, you can see how this makes this display logic
> possible.
>
>
> The other feature is stringification to the id.  <a href=3D"/artist/[%
> cd.artist %]">View CD's artist</a>
> which is a natural way to say "link to the artist object" without thinking
> about the format of the identifier.
>
> Without those features, it seems, people have developed this two accessor
> approach in DBIC.  What those features in CDBI seem to allow is more of an
> abstraction to objects without having to know about the object's
> identifiers.
>

I'll only answer your last issue, since it doesn't make any sense at all in
DBIC context:

...
__PACKAGE__->set_primary_key(qw( part_id customer_id ));
...

The above class has a MultiPK.  In general I don't like MultiPK but the fact
that DBIC supports it allows us to actually use our customer's database.  If
we were to stringify this object how could that work?  Do we do
"$part_id,$customer_id"?

*But* because DBIC is written in such a manner that everything is extensible
you could add this feature in.  I could probably make a component to
stringify my objects to their pk in about half an hour. I won't do it
because I think that's just a silly thing to do; but you can, and that's the
whole point.

Happy hacking!

-- =

fREW Schmidt
http://blog.afoolishmanifesto.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100324/c56=
cc92f/attachment.htm