[Dbix-class] Problem with populate() and commits?

Chris Cole chris at compbio.dundee.ac.uk
Mon May 18 10:03:01 GMT 2009

Peter Rabbitson wrote:
> Chris Cole wrote:
>> To clarify. With autocommit 'off', this code:
>> my $species = $schema->resultset("Species");
>> $species->populate([
>>    { short_name => $shortName,
>>      full_name => $longName,
>>      common_name => $commonName }
>> ]);
>> $species->update();
>> generates this error:
>> DBIx::Class::ResultSet::update(): Values for update must be a hash at
>> ./add_species.pl line 46
>> Issuing rollback() for database handle being DESTROY'd without explicit
>> disconnect().
> Yes, because $species is a resultset, so you are calling resultset update,
> which not surprisingly expects a set of column values to update.

OK, I see where the error is coming from, now. However, how's that
different to this, then [1]:
"To create a new record in the database, you can use the create method.
It returns an instance of My::Schema::Result::Album that can be used to
access the data in the new record:

  my $new_album = $schema->resultset('Album')->create({
    title  => 'Wish You Were Here',
    artist => 'Pink Floyd'

Now you can add data to the new record:


Isn't $new_album a resultset too?

>> It seems that the only way to achieve anything with DBIx is to set
>> autocommit to 'on'. This contradicts the implied transaction handling in
>> the 'Intro' POD which talks about committing changes to the DB. At the
>> very least a note needs adding to the docs regarding DBIx's non-use of
>> transactions.
> I am not sure which part is it that you find contradicting. Please point
> out actual snippets, or even better - provide documentation patches :)

See above. To me, that code snippet implies transactions, but there's no
mention anywhere AFAICS in the Intro or Cookbook PODs regarding the
preferred/assumed use of autocommit and transactions. It's buried in the
link that Peter Rabbitson mentioned.

[1] taken from here:

More information about the DBIx-Class mailing list