On 01/28/2018 09:51 PM, Darin McBride wrote:
tl;dr version: we got past it, but I'm not sure if there is a DBIC metadata
problem or not, and the whole project is moot now.
Right. Re-reading your earlier debug info, I am now almost certain that
this is where things went off the rails:
On Sunday, January 28, 2018 8:36:36 AM MST Peter Rabbitson wrote:
> On 11/16/2015 09:18 PM, Darin McBride wrote:
> > On Monday November 16 2015 7:20:17 PM Peter Rabbitson wrote:
> >> What does this say then:
> >>
> >> Dwarn { $planet_rs->result_source->unique_constraints }
> >>
> >> Something
On 11/16/2015 09:18 PM, Darin McBride wrote:
On Monday November 16 2015 7:20:17 PM Peter Rabbitson wrote:
What does this say then:
Dwarn { $planet_rs->result_source->unique_constraints }
Something screwy is going on with the metadata layer...
{
primary => [
"id"
]
}
This makes
On Monday November 16 2015 10:08:13 AM Peter Rabbitson wrote:
> On 11/16/2015 06:20 AM, Darin McBride wrote:
> > On Sunday November 15 2015 7:09:05 PM Darin McBride wrote:
> > So, the column is:
> >
> > __PACKAGE__->add_columns(
> >
> > name=> { data_type => 'varchar',
On 11/16/2015 07:16 PM, Darin McBride wrote:
On Monday November 16 2015 10:08:13 AM Peter Rabbitson wrote:
On 11/16/2015 06:20 AM, Darin McBride wrote:
On Sunday November 15 2015 7:09:05 PM Darin McBride wrote:
So, the column is:
__PACKAGE__->add_columns(
name=> {
On Monday November 16 2015 7:20:17 PM Peter Rabbitson wrote:
> On 11/16/2015 07:16 PM, Darin McBride wrote:
> > On Monday November 16 2015 10:08:13 AM Peter Rabbitson wrote:
> >> On 11/16/2015 06:20 AM, Darin McBride wrote:
> >>> On Sunday November 15 2015 7:09:05 PM Darin McBride wrote:
> >>> So,
On 11/16/2015 06:20 AM, Darin McBride wrote:
On Sunday November 15 2015 7:09:05 PM Darin McBride wrote:
So, the column is:
__PACKAGE__->add_columns(
name=> { data_type => 'varchar', size => 30,
is_nullable => 0 },
So, explicitly not nullable.
I've added this code as
On Saturday November 14 2015 11:39:04 PM Peter Rabbitson wrote:
> On 11/14/2015 10:46 PM, Darin McBride wrote:
> > DBIx::Class::ResultSet::_construct_results(): Unable to properly collapse
> > has_many results in iterator mode due to order criteria - performed an
> > eager cursor slurp underneath.
On Monday November 16 2015 1:17:55 AM Peter Rabbitson wrote:
> On 11/15/2015 11:23 PM, Darin McBride wrote:
> > Maybe it's just my non-DBIC background, I just figured the DB was giving
> > me
> > everything in the right order already ;) But I guess DBIC is trying to
> > collapse objects so that
On 11/15/2015 11:23 PM, Darin McBride wrote:
Maybe it's just my non-DBIC background, I just figured the DB was giving me
everything in the right order already ;) But I guess DBIC is trying to
collapse objects so that multiple rows with those prefetches will return the
same actual object
On Sunday November 15 2015 7:09:05 PM Darin McBride wrote:
> > Are you saying that you did:
> >
> >
> > __PACKAGE__->add-unique_constraint( ... => [ 'name' ]);
> >
> >
> > AND
> >
> >
> > The 'name' column is *NOT* marked as is_nullable => 1 in the DBIC metadata
> >
> >
> > AND
> >
>
On 11/14/2015 10:46 PM, Darin McBride wrote:
...
order_by => ['me.name'],
...
...
DBIx::Class::ResultSet::_construct_results(): Unable to properly collapse
has_many results in iterator mode due to order criteria - performed an eager
cursor slurp underneath. Consider using ->all() instead at
12 matches
Mail list logo
