[Dbix-class] Implicit prefetch (via select/columns) not supported with accessor 'multi'

Christiaan Kras c.kras at pcc-online.net
Sun Apr 17 12:49:17 GMT 2011


Op 16-4-2011 20:20, Christiaan Kras schreef:
> Op 16-4-2011 19:01, Robert Kinyon schreef:
>> On Sat, Apr 16, 2011 at 10:58, Christiaan Kras<c.kras at pcc-online.net>
>> wrote:
>>> Hello list,
>>>
>>> I've been banging my head against the wall because of an error
>>> message I'm
>>> getting which I wasn't getting before. I'm now using DBIx::Class
>>> 0.08127,
>>> whilst before I believe it was 0.08123.
>>>
>>> I'm constructing my search with the following data:
>>>
>>> my @search = (
>>> { 'modscope.name' => $modscope,
>>> 'me.name' => $module,
>>> 'module_versions.version' => $version,
>>> },
>>> {
>>> join => [qw /modscope module_versions/],
>>> '+columns' => ['module_versions.remote_location'],
>>> }
>>> );
>>>
>>> my $rs = $c->model('DB::Module')->search(@search);
>>> my $row = $rs->first;
>>> ...
>>>
>>> This generates the correct query for my case. The reason I explicitly
>>> tell
>>> it to add the module_versions.remote_location column is because the
>>> module_versions tables contains a BLOB column that can be big. If the
>>> remote_location appears to be empty I'll fetch it in a new call,
>>> otherwise
>>> it redirects the user to the remote_location (this is a Catalyst
>>> application).
>>>
>>> In 0.08123 and 0.08124 this works as I intended and described.
>>>
>>> In 0.08125 and 0.08127 it doesn't and I'm presented with this error
>>> message:
>>> "Implicit prefetch (via select/columns) not supported with accessor
>>> 'multi'". The moment the database call is being made ($rs->first) the
>>> given
>>> error message shows up.
>>>
>>> My question is, is this a bug in DBIx::Class or am I doing something
>>> that
>>> wasn't supposed to work from the beginning?
>>>
>>> If this behavior is intended could one give me directions on how to
>>> refactor
>>> my code? I'm also curious as why this change was made if this is
>>> indeed the
>>> case.
>>
>> The old behavior was a bug. What is happening is that you have a
>> Module->has_many(ModuleVersions). When the +columns happens, DBIC
>> doesn't know that there is only one possible value for
>> module_versions.remote_location. Your query may be able to guarantee
>> this, but DBIC doesn't know that when it's building the query.
>>
>> The simplest fix is to remove the +columns, then traverse the
>> relationship. When you do that, you'll see exactly why DBIC cannot
>> assume anything.
>>
>> Alternately, prefetch module_versions. :)
>>
>
> OK, that makes sense.
>
> With prefetching am I able to exclude a column from the query? Like I
> said the reason I was doing this was because one of the columns is a
> BLOB. Otherwise I should perhaps look at storing this data somewhere
> else (perhaps another dedicated table).
>

Figured out I can pass the columns attribute to search_related as well 
to restrict the columns to select, so my problem has been solved.


-- 
Christiaan Kras
http://blog.htbaa.com



More information about the DBIx-Class mailing list