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

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

> What do you think about my suggestion? I offered the following:
> 
> Any database connection has the default transaction that is controlled
> by AutoCommit attribute and by the additional attributes of "prepare",
> "do"  and  the  like methods.
> $sth = $dbh->prepare("select ...", { tr => \%params });

fine with me. the code could be smart, and if tr is a scalar, parse it as SET TRANSACTION,
and if it is a hash, deal with it as, um, a hash.

i don't think it should be called "tr", to distinguish it from a transaction handle --
these are just transaction parameters. 
could be "TransParams" or something.

> 
> Besides  that the user may assign as many named transactions as he (we
> Russuan  call  user  ALWAYS  "he"  ;-) ) likes by the syntax:
> $tr = $dbh->begin(\%params).

there will always be other options, and for symmetry, i think this should be:
begin({TransParams => \%params});

> 
> This  transaction  object  has  the  same  methods  as  $dbh has, i.e.
> prepare, execute, selectrow_array and others.

What I would like is for the methods to all support a {Trans => $tr} or {TransParams => $string}
or {TransParams => $hash} in their options argument.
In other words, i don't see a need to make the transaction handle also be
an object with methods, though I suppose it couldn't hurt.

> This  model doesn't conflict with "SET TRANSACTION" syntax because the
> parameters  can be named the same, so you need not to develop your own
> documentation. 
> I would like this, but you, of course, may disallow it, and I would do
> nothing  with  it but to resent and to write my transactions by my own
> :-)

You actually have two proposals above -- one on how to specify parameters,
and one on how to change the api. Both seem fine to me, but in the end it
is Edwin who rules....

-mda