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

[Peter Rabbitson]

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

See below
> 
>   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.

>>> 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.
> 

I am still confused sorry... but really trying to understand. What makes
you believe that the above example _implies_ transactions?