[Dbix-class] PATCH: Support for arbitrary SQL in relationship definition

Rob Kinyon rob.kinyon at gmail.com
Mon Jun 29 12:57:02 GMT 2009


On Wed, Jun 10, 2009 at 16:23, Daniel Ruoso<daniel at ruoso.com> wrote:
> Hi,
>
> For some reason this patch is sitting on my local git copy for a while,
> and now I'm not sure it was even sent at some point... /me--
>
> So, here goes a patch against current 0.08 trunk to support arbitrary
> SQL in the join condition with an included test, which allow something
> like:
>
> __PACKAGE__->has_many(
>    cds_90s => 'DBICTest::Schema::CD',
>    { 'foreign.artist' => 'self.artistid',
>      'foreign.year' => \"LIKE '19%'" }
> );

I've been thinking about this for a while, then I forgot to reply
until ribasushi poked me about it.

I understand the desire to build something like this. Everyone wants
everything to be accessible from everywhere. Here's my problem:

A relationship is nothing more than the following:
    * An installed method that generates a resultset
    * a piece of metadata used by search() and update() to do automagical things

Your cds_90s example could be better written as follows:

    sub cds_decade {
        my $self = shift;
        my ($decade) = @_;

        return $self->cds({
            year => { like => "19$decade" },
        });
    }

    sub cds_90s { shift->cds_decade( '90' ) }

Unless, of course, you actually want to join on cds_90s, in which case
you might be better served to use a subquery in your join clause.

Now, I'm not arguing that it shouldn't be done. However, I'm still
trying to understand the usecase-space. APIs are forever - while we
have workarounds, it behooves us to think things through.

Rob



More information about the DBIx-Class mailing list