"Roman Rokytskyy" <rrokytskyy@...> wrote:

>
> I have uploaded a document describing an implementation proposal for
> the external procedures interface. The proposal is based on the JavaSP
> implementation for Firebird that was presented some time ago in the
> Firebird-Java group. The code seems to be quite stable, so we would
> like to discuss whether it can be accepted as a generic interface to
> support external procedures in different languages (Java, C#, Delphi,
> PHP, Perl, JavaScript, etc.).

Well, most of these ideas were already discussed, so I don't have much new
to say :-)

First question: should we discuss external functions here as well or is this
a subject of a separate talk?

> During initialization module is required to register itself in the
> RDB$EXTERNAL_ENGINE table using simple INSERT statement. Below is
> an example for Java ESP engine.

I don't like the idea of self-registering modules. They could be described
via the manifest files or they could contain a pre-defined describe() call,
but this is the engine that decides to write something into the system
tables.

> When the external procedure is called, server reads the metadata
> from the RDB$EXTERNAL_PROCEDURE table and finds the name of the
> module.

How is the module name encoded in RDB$EXTERNAL_NAME?

> Using this name server obtains a reference to an object that is
> stored on the module initialization (usually happens on server start)

Shouldn't the external module be loaded on demand?

> ExternalProcedure getProcedure(ISC_STATUS* status, char* externalName)

const char* externalName, please ;-)

> ResultSet::close(...) is called automatically when

ExecuteProcedure::close(...)

> is called and the result set was not closed before.

I think that the ExternalResource::close() implementation must be required
to be tolerant to being called multiple times.

> It is prohibited to spawn new threads from within the external procedures
> because spawned thread will no longer be able to connect to the database
> from which the external routine was invoked

I'd restate this as: "It is prohibited to access the internal database
attachment from threads spawned from within the external procedures". And
I'd expect the implementation (the engine?) to return an error otherwise. I
see no problems with spawning multiple threads for the
computation/communication purposes, neither with accessing databases via new
explicitly made attachments.

> Implementation in this case is required to return NULL from the call.

Is the engine expected to return an error if the external procedure called
via EXEC PROC returned a result set object or should it silently ignore the
result set?


Dmitry



Dmitry