Skip Menu |
 

This queue is for tickets about the DBIx-Class CPAN distribution.

Report information
The Basics
Id: 102754
Status: resolved
Priority: 0/
Queue: DBIx-Class

People
Owner: Nobody in particular
Requestors: KBENSON [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.082801



Subject: populate silently drops data if first hashref contains less items than subsequent hashrefs
Download (untitled) / with headers
text/plain 1.1k
When DBIx::Class::ResultSet::populate is calles with an arrayref of hashrefs, it generates a column list from the keys of the first hashref. If the subsequent hashrefs for insertion include hash keys that were not included in the first hashref, but are valid fields, they are silently ignored. E.g. Table foo has fields field_1, field_, field_3. my @populate_items = ( { field_1=>10, field_3=>30 }, { field_1=>10, field_2=>20, field_3=>30 } ); Schema->resultset('Foo')->populate( \@populate_items ); DBIC_TRACE=1 shows the query generated will be equivalent to: INSERT INTO `foo` ( `field_1`, `field_3` ) VALUES ( ?, ? ): '__BULK_INSERT__' This has to do with how populate determines the columns in the void context case. This one bit me pretty hard, I have a populate that happens once a day has a small percentage of it's items missing some views. IF the first item happened to be one missing a field, subsequent items for that populate were all missing that field. I understand if in the name of keeping this a fast path this behavior needs to stay, but the warning about how context matters should definitely be updated to reflect this case. Thanks!
Subject: Re: [rt.cpan.org #102754] populate silently drops data if first hashref contains less items than subsequent hashrefs
Date: Sat, 14 Mar 2015 09:44:37 +0100
To: bug-DBIx-Class [...] rt.cpan.org
From: Peter Rabbitson <ribasushi [...] cpan.org>
Download (untitled) / with headers
text/plain 691b
On 03/13/2015 11:43 PM, Kevan Benson via RT wrote: Show quoted text
> > When DBIx::Class::ResultSet::populate is calles with an arrayref of hashrefs, it generates a column list from the keys of the first hashref. If the subsequent hashrefs for insertion include hash keys that were not included in the first hashref, but are valid fields, they are silently ignored.
This has been fixed about a year ago https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082810/Changes#L61. The commit message explains why it took so long: https://github.com/dbsrgits/dbix-class/commit/d0cefd99 Please let me know if the fix in 0.082810 is indeed solving your problem, as it is possible something *still* got missed.
Subject: Re: [rt.cpan.org #102754] populate silently drops data if first hashref contains less items than subsequent hashrefs
Date: Sat, 14 Mar 2015 11:10:21 -0700
To: bug-DBIx-Class [...] rt.cpan.org
From: Kevan Benson <kentrak [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
I could have sword I updated recently, but apparently I'm on 0.08270. In any case, I should have checked the most recent code for the bug, and I forgot that step. Thanks for the quick response, I'll confirm it's functioning on my side and if not reply back, but you should be able to close this in the meantime. Thanks again! On Sat, Mar 14, 2015 at 1:44 AM, Peter Rabbitson via RT < bug-DBIx-Class@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=102754 > > > On 03/13/2015 11:43 PM, Kevan Benson via RT wrote:
> > > > When DBIx::Class::ResultSet::populate is calles with an arrayref of
> hashrefs, it generates a column list from the keys of the first hashref. > If the subsequent hashrefs for insertion include hash keys that were not > included in the first hashref, but are valid fields, they are silently > ignored. > > This has been fixed about a year ago > https://metacpan.org/source/RIBASUSHI/DBIx-Class-0.082810/Changes#L61. > The commit message explains why it took so long: > https://github.com/dbsrgits/dbix-class/commit/d0cefd99 > > Please let me know if the fix in 0.082810 is indeed solving your > problem, as it is possible something *still* got missed. > > >


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.