Re: [Dbi-interbase-devel] 0.21 alpha released

[Mark D. A. <md...@di...>]

> This simply didn't cross my mind, but $tr->commit is more elegant, I
> hope,   than  $dbh->commit(Trans  =>  $tr),  so  $tr->prepare(...)
> looks  slightly  shorter and clearer than $dbh->prepare(..., {Trans =>
> $tr}).

ok, but i think the non-OO api should also be available because
some rdbms's don't consider a "prepare" to be transactional, and we should
have some hope that what we do here will be a guide for other DBI drivers
to follow when adding transaction support.

indeed, i assume that interbase supports a statement being prepared
in one transaction and executed in another. it would be kind of silly
to have to re-prepare a statement for every transaction using it; i usually
prepare all my statements at program startup time.

> 
> BTW,  it  $dbh  and  $sth  seem  to  have  the  method or the property
> returning   the   current   transaction.   Smth   like   $dbh->tr   or
> $dbh->{Trans}.

I'd rather call it "default transaction" than "current transaction".
Also, it should be recognized/documented that $dhb->DefaultTrans() may return null
(when autocommit on and a commit or finish has been done; or when autocommit is
off and explicit transactions are always used.)

One of the things I'm glad that edwin has cleaned up in his re-write is that in AutoCommit=on,
the default transaction exists only on demand (as opposed to the previous approach of
always starting one when the previous one commits).
This is a good step towards allowing a user-specified transaction handle or transaction
parameters regardless of the AutoCommit setting. 

AutoCommit off still has a clunky/limited interface, but that isn't edwin's fault, that is the
immature DBI interface that has a "commit" and "rollback" but no "begin".

(btw, I am still hoping that i can convince edwin to not do isc_commit_retaining in commit()
by default, but instead to make that behavior an option -- combined with the default transaction
parameter of snapshot isolation, it would generally have bad effects with multiple writers.)

How is this as a summary of what we might do:

1. Allow specifying the transaction parameters that should be used when the driver creates
any default transaction on behalf of the programmer. This would be done by setting
the option DefaultTransParams, which can be specified at connect() time, or by setting
$dbh->{DefaultTransParams} later. The value can be a string or a hash.
Unlike the case of changing the value of AutoCommit, changing DefaultTransParam
has *no* affect on the current transaction, only on the next one made.

2. Allow creating a transaction handle, via $trh = $dbh->BeginTrans({%options})

3. Allow specifying the transaction handle to use on any $dbh method, by adding a
{%options} argument at the end; one of the options can be Trans => $trh.

4. Allow the same options argument for certain $sth methods: execute() and do().
Note that if someone does $sth = $dbh->prepare($stmt, {Trans => $trh}),
then $trh is used as the default transaction for all methods on the $sth -- *unless* the
programmer specifies a Trans option for execute() or do(), which means that
a different txn is used for the two steps.

5. Support (3) to be done in an OO way, so that $dbh->whatever(..., {Trans => $trh, %options})
is the same as $trh->whatever(...,{%options}).

Note that:
(i) I am not suggesting that (4) be done OO: $trh->execute() would imply a concept
of a "current statement" for a transaction, or some such messiness.
(ii) Despite what I may have posted earlier, I am not suggesting that we support
a "TransParams" option that sets the transaction parameters for the default transaction
for just this operation. The programmer must either set DefaultTransParams, which
affects all future default transactions created, or must provide a Trans, which is a transaction
handle created how she likes.
(iii) I am also not suggesting a the ability to set a DefaultTrans, only set DefaultTransParams.
The value of DefaultTrans can be read, not written. It is always something allocated
automatically within the driver, if it exists at all. Its allocation/deallocation is managed
within the driver.

> The  one  issue  else:  what  must  we  do  with  transaction  on it's
> destroying?  If  it's  enough  just  commit  or  rollback,  maybe  the
> parameter named, say, AutoCommit will be useful.

I think a different option should be used, such as 'FinishAction'.
So a person could specify $trh->{FinishAction} = 'commit', 'rollback', 'abandon', 'error'.
The FinishAction could also be specified as an option when creating the transaction, as in
$dbh->BeginTrans({FinishAction => 'commit'}).
'commit' means call $trh->commit() automatically.
'rollback' means call $trh->rollback() automatically.
'abandon' means "do not call any rdbms operations automatically, just free your memory"
(this is because some rdbms's treat this differently -- believe that a in interbase, explicitly
aborted transactions take up space over time, while merely abandoned ones do not.)
'error' means to die or set err, according to RaiseError.
The default would be 'error'.

> MDA> You actually have two proposals above -- one on how to specify parameters,
> MDA> and one on how to change the api.
> 
> Thank you, your words sound like nectar and ambrosia taste :-)

How can i live up to that? :)

-mda