Re: [Firebird-devel] Providers, yvalve, external engines and object lifecycle

[Adriano d. S. F. <adr...@gm...>]

On 28-03-2011 11:52, Alex Peshkoff wrote:
>  On 03/28/11 18:28, Adriano dos Santos Fernandes wrote:
>> On 28-03-2011 06:10, Alex Peshkoff wrote:
>>> This need happened due to my attempt to emulate old ISC API too careful :-)
>>> All the cases when we need both attachment & transaction are due to my
>>> wrong understanding (when writing interfaces for yvalve) of how should
>>> multiDb transaction work.
>>> Such transaction should have same interface as single database one, but
>>> absolutely other implementation. This implementation is
>>> provider-independent, therefore can be placed in master interface.
>>> startMultiDbTransaction() creates a container holding pairs -
>>> IAttachment* which started transaction and started ITransaction*. All
>>> functions like createBlob() go to ITransaction. Normal implementation
>>> ignores IAttachment* parameter. MultiDb implementation searchs in
>>> internal container for appropriate IAttachment* and calls same function
>>> for found transaction. No more casts - and therefore no need in
>>> additonal checks. And yes - one can safely mix attachments, created by
>>> different providers, in such MultiDb transaction.
>>>
>>> I.e. I still do not see where do we need to do additional checks.
>>>
>> The scheme of put openBlob and others in transaction was very evil, and
>> complete different than the way others things worked.
> 
> What others things? Why evil?
> When was openBlob in transaction?
>> With it, you created this notion of passing a null attachment. 
> 
> ???
> 

---------------------
Revision: 52587
          http://firebird.svn.sourceforge.net/firebird/?rev=52587&view=rev
Author:   asfernandes
Date:     2011-03-21 21:56:47 +0000 (Mon, 21 Mar 2011)

Log Message:
-----------
Move transactRequest, createBlob, openBlob, getSlice, putSlice and ddl
from ITransaction to IAttachment.

It's better to have one standard than two, and "ddl" was broken from API
POV.
So make the IAttachment always the caller, explicit or implicit (via
IStatement or IRequest), and pass the ITransaction as parameter.
---------------------

What you were doing was to make possible to call
transaction->createBlob(..., attachment = NULL) for single transactions,
but sure this is impossible to work with multidb transactions.

So you needed the IAttachment for them, and it would be need to be
casted as we were talking. Also, engine was receiving a bogus
IAttachment and just validating it.

>> But you
>> would need it in multidb transactions, then, you would still need the
>> casts, 
> 
> With described approach I will not need casts.
> 
>> and at the same time make programs difficult to change from
>> single to multidb transactions if needed.
>>
> 
> There will be absolutely no difference in program when changing from
> single to multiDbTransactions.
> Except the start of transaction itself - but one will anyway need to
> have >1 attachment, i.e. changes here are unavoidable. When multidb
> transaction is started, one will work with it in exactly same way as
> with single db. It's same interface, just different implementations.
> 
As I said above, multidb transaction can't receive a null attachment and
work before my change, but this worked with singledb transction.


Adriano