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

[Bill Moseley]

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 often
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 when 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 already
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.



-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100324/92a=
e8fe9/attachment.htm