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

Peter Rabbitson rabbit+dbic at rabbit.us
Mon May 18 14:34:09 GMT 2009

Chris Cole wrote:
> 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.

So where is the doc patch to make it clearer?

>>>> 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:
>   $album->update;
> 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.

my $row = $resultset->new_result (\%values);

is the same as

my $row $resultset->create (\%values)

$row->col_a ('stuff');
$row->set_column (col_b => 'stiff')

is the same as

$row->update ({ col_a => 'stuff', col_b => 'stiff' });

Now this is the extent of help I am giving for free. For more you will
need to pay back with doc patches :)

In general remember that DBIC _never_ assumes transactions on your behalf,
except for internal racy code. Transaction handling is your responsibility.


More information about the DBIx-Class mailing list