|Subject||Re: [Firebird-Architect] External Engines Implementation Details|
> Vlad Khorsun escreveu:Why SYSDBA ? It can be any account granted to read corresponding items.
>>> 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.
> Another connection type is the one to executeThis is current (or internal) connection. And we don't need to do something
> functions/procedures/triggers. This one needs user rights.
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 inHmm... EE may ask engine about charset of current connection and work
> different environment from the user, so user charset should not
> interfere with it.
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 thePass charset name into DPB when obtaining handle of current connection ?
>>> 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.
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 viewI don't understand both statements. Explain, please
>> 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.
>>> It also can have user or sysdba rights.I see two *different* connections - one is for internal needs (metadata handling, etc)
>> Can you explain more on this ?
> Already explained above... For EE metadata handling. And also, this is
> required for future internal SQL metadata handling.
and second is in user's context.
>>> Different charsets are also needed for future implementation of internalI can understand two attachments...
>>> 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.
> For engine, only entry points functions understand the pseudo...but i don't think "pseudo attachment" is a way to go.
> attachment, transforms it to real attachment. For monitoring purposes,
> there is only one attachment.
>>> I also need to communicate y-valve handles to engine, as Vlad does inI don't like this hack. I prefer to introduce private jrd8_attach_database2 call
>>> 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
>> 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.
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) structuresI'd said this is because DSQL is not properly integrated into engine (still !) ;)
>> 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.