|Subject||Re: External procedures: implementation proposal.|
> Don't store RDB$MODULE_NAME in RDB$EXTERNAL_ENGINE. Use the configOk, this is possible, though I do not like config files - embedded
Vulcan is much less transparent in this regard than FB-embedded. With
fbembed.dll I can access my databases without configs, in Vulcan that
seems no longer to be possible - I have to configure providers. This
is no longer a DBA-free engine from my POV.
> Don't initialize RDB$EXTERNAL_ENGINE at CREATE DATABASE. It'sGood suggestion.
> problematic for backup and restore.
> Create a DDL statement: CREATE EXTERNAL ENGINE ...
> A C++ API is okay for Java and .NET that the project will distributeI hope that Vlad can tell something more here - he was able to create
> the engines. But C++ programmers will need to use the same compiler
> vendor/version or compile everything all the server.
> The API is very small. Why not use C and distribute the C++ bridge
> for external engine writers?
a Delphi-based external procedure with this API.
> Could I consider that "virtual ExternalProcedureYes, you're right.
> getProcedure(ISC_STATUS* status, char* externalName) = 0;" mean
> "virtual ExternalProcedure* getProcedure(ISC_STATUS* status, const
> char* externalName) = 0;"? Note the ExternalProcedure*.
> Why ExternalResource class exist? Why create a "close" method thatNot only "delete this". If I open a connection to another database
> we know that will do "delete this"?
> Use a virtual destructor.
(Oracle for example) and start pumping records into Firebird, I need
some method to tell me "now you can stop and disconnect". I think this
would be possible to achieve with virtual destructor too, but explicit
method call seems to be logical here.
> I think ResultSet::getValue should be replaced withSounds logical, but only if we agree that PARAMDSC or something
> ResultSet::getValues getting all the return values in one call.
similar is used to pass values in and out of the procedure. And from
Jim's POV this can be answered only after answering the question about
So now I'm learning Vulcan and try to understand what advantage does
the InternalConnection & Co. bring and why the struct with "ISC
API"-like entry points plus two handles corresponding the public
db_handle and tr_handle would not work or would be more inefficient
Basically the structure with entry points is how it works now (at
least in JNI layer that binds Fyracle and Java part), plus one more
call to fetch current db and tr handles for the current context.