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

Chris Cole chris at compbio.dundee.ac.uk
Mon May 18 13:50:23 GMT 2009

Peter Rabbitson wrote:
> Chris Cole wrote:
>>   my $new_album = $schema->resultset('Album')->create({
>>     title  => 'Wish You Were Here',
>>     artist => 'Pink Floyd'
>>   });
>> Now you can add data to the new record:
>>   $new_album->label('Capitol');
>>   $new_album->year('1975');
>>   $new_album->update;"
>> Isn't $new_album a resultset too?
> No, $new_album is an actual row object, something that has columns set
> to _specific_ values, something that represents a row, not a bunch of
> rows under a SELECT. Suggest a better wording to make this clearer.

Indeed. As a novice to this class (but not perl) this is /far/ from clear.

>>> 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.
> I am still confused sorry... but really trying to understand. What makes
> you believe that the above example _implies_ transactions?

The '$new_album->update' bit. To me at least, it implies that the
additions are not made immediately, but only after the update() command
is sent.

Also the preceding section [1] of the POD also has:
"Just like with Class::DBI, you call update to commit your changes to
the database:


If needed, you can throw away your local changes:

  $album->discard_changes if $album->is_changed;

As you can see, is_changed allows you to check if there are local
changes to your object."

So, in the context of the page 'update' is clearly implicated with
transactions. To the unknowing eye there's no obvious difference between
the two 'update' commands.


More information about the DBIx-Class mailing list