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

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

On 25-03-2011 05:27, Alex Peshkoff wrote:
>  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.
> 
This seems ok.

What I had in mind:
- Yvalve handles are mapped to Yvalve objects (YAttachment, YTransaction).
- We add new API function that translate Yvalve pointer to handle:
fb_get_handle(IInterface*, int type)

And with your suggestion, then we add a way to make the Yvalve to create
a Yvalve object from a provider object, so external code always access
provider objects via Yvalve objects. And since external code now
receives a Yvalve object, it can gets its legacy handle with fb_get_handle.


Adriano