> Roman Rokytskyy wrote:

>> It's been a while since we have published a document describing possible
>> architecture to support external procedures written in different
>> languages. Today we have released first preview version of Java support
>> in Firebird.
>>
>>
>>
> It would be both easier to use, easier to implement, and easier to
> maintain if you actually passed the parameters necessary for triggers,
> udfs, and procedures rather than requiring them to call static procedure
> to pick these things out of the ether.

We can implement that scheme too. In fact, if you check our ExternalSP
design (a document posted in Firebird-Architect files area), you would
notice something called ProcedureContext and TriggerContext.

Current scheme complies more or less with the SQLJ "standard" (an Oracle any
Sybase implementation, but IIRC it is also supported by JDataStore,
Cloudscape, DaffodilDB, etc). I believe we should not require people to port
their Java code to Firebird calls when they use scheme that is believed to
be a standard one.

> In Netfrastruture, which has had an embedded Java implementation for
> five years, the signature for a trigger method is:

> public static void methodName (Connection connection, Record
> oldVersion, Record newVersion, int type)
> ...
> A key issue for triggers is metadata access. Existing Firebird triggers
> are necessarily single table, so built in knowledge of metadata isn't a
> problem. Java triggers, on the other hand, are naturally table
> independent, so building in a mechanism for rapid, context sensitve
> access to metadata is critical.
> ...
> The methods "nextColumnId" and "nextPrimaryKeyColumn" allow rapid
> iteration through all fields or primary keys, for example:
>
> for (int n = -1; (n = record.nextPrimaryKeyColumn (n)) >= 0;)
> key += record.getString (n) + "^";
>
> The rest of the methods are necessary for metadata and data access and
> data update.

Thanks! I will try to address this in the production version, but my
personal primary goal is to stabilize the ExternalSP API first. Personally
I'm a bit disappointed that it gathered almost no interest within the
Firebird developers. Maybe people do not need it?

Roman