Subject | Re: [Firebird-Architect] Re: External procedures: implementation proposal. |
---|---|
Author | Jim Starkey |
Post date | 2005-07-21T19:59:32Z |
Adriano dos Santos Fernandes wrote:
not the mechanism behind it. An Java implementation of external
procedures would probably return an implementation of ResultSet that
navigated the corresponding Java objects with JNI. In all likelihood,
the Java ResultSet would itself be a Java wrapper around the C++
InternalResultSet (also implementation of ResultSet). This would give
the Java procedure code full access to internal engine SQL in the
context of the client database attachment.
requests. A compiled procedure is virtual indistinguishable from an
ordinal request or trigger request. The internal request mechanism,
however, is just that -- internal -- and not something we would ever
want to export to an external library. The internal SQL implementation,
on the other hand, is squeeky clean, stable, and passes over dynamic
libraries boundaries without problems.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>Jim Starkey escreveu:It shouldn't be. The abstract class ResultSet specifies only the API,
>
>
>
>>The external procedure, if appropriate, should return an instance of ResultSet.
>>
>>
>>
>Isn't it a problem for procedures that return too many rows?
>
>
not the mechanism behind it. An Java implementation of external
procedures would probably return an implementation of ResultSet that
navigated the corresponding Java objects with JNI. In all likelihood,
the Java ResultSet would itself be a Java wrapper around the C++
InternalResultSet (also implementation of ResultSet). This would give
the Java procedure code full access to internal engine SQL in the
context of the client database attachment.
>Do normal SPs work in that way too?Nope. Not even close. The internal procedures are turned into BLR
>
>
>
>
requests. A compiled procedure is virtual indistinguishable from an
ordinal request or trigger request. The internal request mechanism,
however, is just that -- internal -- and not something we would ever
want to export to an external library. The internal SQL implementation,
on the other hand, is squeeky clean, stable, and passes over dynamic
libraries boundaries without problems.
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376