> Vlad Khorsun escreveu:
>>> As you see in my external engine API proposal, it creates something we
>>> current don't have internally. One attachment can have different
>>> properties depending on the context.
>>>
>>
>> Is it really good and necessary ?
>>
> Yes. In External Engine, there may be two logical connection types.
>
> One is for the Engine itself manage metadata. Not all engines is dumb,
> they need to inspect metadata to load things (example: .class file
> stored in blob). And planning security from the start, such type of
> information should not be available to users. This logical connection
> generally can work with UTF-8 and should have SYSDBA rights.

Why SYSDBA ? It can be any account granted to read corresponding items.

> Another connection type is the one to execute
> functions/procedures/triggers. This one needs user rights.

This is current (or internal) connection. And we don't need to do something
with its rights.

> And we can't guess the charset they want.

We must not guess it. They just must work with attachment charset.

> Also, it's another client, running in
> different environment from the user, so user charset should not
> interfere with it.

Hmm... EE may ask engine about charset of current connection and work
with it as is (no transliteration) or we may introduce transliteration (INTL)
services for EE to do it.

>>> For example, it can use one charset to the client and another to the
>>> external engine.
>>>
>>
>> Why do we need such complexity ? I think we must make life of external
>> engine (EE) developers much easier than our ;) I mean - there is no sense
>> to force EE to work with all possible charset's supported by FB.
> I don't think your argument is correct. This "complexity" makes our
> (engine developers) live a bit less-easier. EE developers can just pass
> a charset name.

Pass charset name into DPB when obtaining handle of current connection ?
Hmm... ok. But then engine must remember it on per-EE basis for every attachment
and perform transliteration on every call of ESP\EUDF, right ?

>> At my view
>> two is enough - NONE (no transliteration between engine and EE) and UTF-8
>> (as common denominator for all charsets).
>>
>> Not all applications require more than one charset to work with. Most european
>> and american developers may work with one-byte encoding - plain ASCII, i think.
>> They can use NONE (i called it fb_string_ascii in Fyracle) in most cases. All other
>> will work with good known UTF-8.
>>
> This may be true only in managed (JVM / .NET) environments. I don't
> think we should break all INTL concept of transliteration and client
> charset for nothing.

I don't understand both statements. Explain, please

>>> It also can have user or sysdba rights.
>>>
>>
>> Can you explain more on this ?
>>
> Already explained above... For EE metadata handling. And also, this is
> required for future internal SQL metadata handling.

I see two *different* connections - one is for internal needs (metadata handling, etc)
and second is in user's context.

>>> Different charsets are also needed for future implementation of internal
>>> SQL, as engine SQL is expected to work with metadata (UTF-8) charset
>>> independently of user charset. The same for user / sysdba rights.
>>>
>>> To make it work, I need to:
>>> - create a REATTACH y-valve internal function
>>> - create the concept of "pseudo attachments"
>>>
>>> A "pseudo attachment" is resolved in DSQL and engine entry points and
>>> changes the real attachment properties and continues with it.* This
>>> seems to not be a problem for multi-thread, as multiple threads can't
>>> use the same attachment simultaneously. (is this simple correct?)
>>>
>>> * Dynamic properties can also live in the thread data, but this is
>>> enough for current implementation IMO.
>>>
>>
>> Is it something like ALTER SESSION ?
>>
> Not exactly.
>
> For user, it's more like two attachments.

I can understand two attachments...

> For engine, only entry points functions understand the pseudo
> attachment, transforms it to real attachment. For monitoring purposes,
> there is only one attachment.

...but i don't think "pseudo attachment" is a way to go.

>>> I also need to communicate y-valve handles to engine, as Vlad does in
>>> exec. stmt branch. But the solution Vlad is using doesn't work with
>>> CONNECT and TRANSACTION START triggers, as he said.
>>>
>>
>> Yes. I think when DSQL will be moved inside engine this issue will disappear
>>
>>
>>> I think these handles could be communicated to the engine via internals
>>> DPB/TPB.
>>>
>>
>> Are you going to pass y-valve handle (or its address) via DPB/TPB ?
>>
> This solve the problem with database triggers.
>
>> Or i, very probably, not understand something ?
>>
> Since it's from y-valve to internal engine, I see no problem except
> establish a generic DPB/TPB mechanism for this.

I don't like this hack. I prefer to introduce private jrd8_attach_database2 call
with additional argument to do it. I prefer much more to leave it as is until
integration of DSQL into engine.

>>> - ugly API, where engine doesn't understand client (DSQL) structures
>>>
>>
>> Not sure i understand this
>>
> Vulcan Engine8 class can handle only BLR messages, and Dispatcher can
> handle DSQL structures. Both are derived from Subsystem that implements
> both ways throwing error.
>
> It's very bad designed.

I'd said this is because DSQL is not properly integrated into engine (still !) ;)

Regards,
Vlad