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

[Alex P. <pes...@ma...>]

 On 03/24/11 20:28, Adriano dos Santos Fernandes wrote:
> On 24-03-2011 12:53, Alex Peshkoff wrote:
>>  On 03/24/11 18:09, Adriano dos Santos Fernandes wrote:
>>> On 24-03-2011 11:59, Alex Peshkoff wrote:
>>>> May be you have forgotten - one of my proposals is to not pass external
>>>> handles in attach/startTransaction call. And do not pass them into
>>>> engine in any way. Cause with new API we have much better way to access
>>>> current context.
>>>>
>>> If your approach is about don't be able to use current Firebird API with
>>> external attachments and transactions (initiated by client or
>>> internally), I'm sorry but I can't consider it as usable.
>> May be you've missed in the thread 'Refcounted API objects':
>>
>> We really need converter from ISC API to new interface. If in external
>> engines we
>> add 2 special handle values - current connection and current
>> transaction, this will solve backward compatibility problem in all places.
>>
> Single handle meaning different things when used in different moments
> smells like fire to me.

Yes, probably you are right. Even if we take into an account existence
of current_user and current_role variables - I agree that this is
another usage.

But no matter of that fact delivering of original ISC handles into
engine is also bad idea. And one of the reasons for it - in many cases
there will be nothing to deliver. Server with new interface will work
without ISC handles at all, therefore to support old API in external
engines you will anyway have to create a kind of pseudo ISC handle.
There is absolutely no crime in it - just make it possible to ask API
converter: I have IAttacment* (or ITransaction*), please create handle
for it.