[Dbix-class] columns and prefetch and columns => undef.

Bill Moseley moseley at hank.org
Mon Jun 18 14:58:11 GMT 2012


The "columns<http://search.cpan.org/~arodland/DBIx-Class-0.08196/lib/DBIx/C=
lass/ResultSet.pm#columns>"
attribute does not document what to do if set to undefined.  What I've been
using it for in the past was to "reset" the column selection but to all
columns.  This worked in older versions.   Please see the examples below:

So, the main question is what is the expected behavior when columns =3D>
undef is used.  Or rather, what can I do to "reset" the column selection
when used with prefetch?

Here's an example.


In my code I get passed a resultset that has had columns =3D> \@cols applie=
d.
  But, later I wanted to remove that selection of a subset of columns.

$rs =3D $rs->search(
    {},
    {
        prefetch =3D> 'foo',
        columns =3D> undef,
    },
);


The idea was to remove the column limitation.   This worked in 0.08123.
 Here's a demo:

I'm using the Artist and CD per the documentation with this code:

my $rs =3D $schema->resultset( 'Artist' )->search(
    {},
    {
        columns =3D> [qw/ artistid col1 /],  # I added col1 .. col9
    },
);


print Dumper $rs->as_query;

$rs =3D $rs->search({},
    {
        prefetch =3D> 'cds',
        # columns =3D> undef,
    },
);

print Dumper $rs->as_query;


So on 0.08123 I see this with "columns =3D> undef" *commented out*:

$VAR1 =3D \[
            '(SELECT *me.artistid, me.col1* FROM artist me)'
          ];
$VAR1 =3D \[
            '(SELECT *me.artistid, me.col1, cds.cdid, cds.artistid,
cds.title, cds.year* FROM artist me LEFT JOIN cd cds ON cds.artistid =3D
me.artistid ORDER BY cds.artistid)'
          ];



So, the same limited columns are include along with the prefetched columns.

Now, using *columns =3D> undef* I see this on the old DBIC version.

$VAR1 =3D \[
            '(SELECT me.artistid, me.col1 FROM artist me)'
          ];
$VAR1 =3D \[
            '(SELECT me.artistid, me.name, me.col1, me.col2, me.col3,
me.col4, me.col5, me.col6, me.col7, me.col8, me.col9, cds.cdid,
cds.artistid, cds.title, cds.year FROM artist me LEFT JOIN cd cds ON
cds.artistid =3D me.artistid ORDER BY cds.artistid)'
          ];



So, in the case above using *columns =3D> undef* essentially resets the
column bringing in all the

Now with current 0.08196 I'm seeing this, first with columns =3D> undef
*commented
out*.

$VAR1 =3D \[
            '(SELECT me.artistid, me.col1 FROM artist me)'
          ];
$VAR1 =3D \[
            '(SELECT *me.artistid, me.col1*, cds.cdid, cds.artistid,
cds.title, cds.year FROM artist me LEFT JOIN cd cds ON cds.artistid =3D
me.artistid ORDER BY cds.artistid)'
          ];


Now, with *columns =3D> undef -- this is the change in behavior:*

$VAR1 =3D \[
            '(SELECT me.artistid, me.col1 FROM artist me)'
          ];
$VAR1 =3D \[
            '(SELECT cds.cdid, cds.artistid, cds.title, cds.year FROM
artist me LEFT JOIN cd cds ON cds.artistid =3D me.artistid ORDER BY
cds.artistid)'
          ];

So, in this last case columns =3D> undef now *removes* all the columns from
the resultset if there's a prefetch.

Without the prefetch AND columns =3D> undef as:

$rs =3D $rs->search({},
    {
        #prefetch =3D> 'cds',
        columns =3D> undef,
    },
);


I see:

$VAR1 =3D \[
            '(SELECT me.artistid, me.col1 FROM artist me)'
          ];
$VAR1 =3D \[
            '(SELECT * FROM artist me)'
          ];


So, in this case it looks like the columns =3D> undef is suppose to reset to
selecting all columns -- but only if there's not also a prefetch.

Since it doesn't seem to be documented I'm not sure what the correct
behavior is suppose to be, but in the second example above it removes ALL
columns except the prefetched columns, which does not seem correct.


What is the correct behavior, and how can I achieve the the old behavior of
"columns =3D> undef"?

Again, I'm getting passed a resultset so I don't really know what the
columns should be, so I cannot easily (in a generic way) set columns to an
array ref.



-- =

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


More information about the DBIx-Class mailing list