Subject | Re: [Firebird-Architect] Java Stored Procedures |
---|---|
Author | Jim Starkey |
Post date | 2005-10-20T13:40:46Z |
Ian A. Newby wrote:
of concept" breaks the product layering and is unimplementable in
Vulcan. The issue has to do with how SQL callbacks are performed. In
the proof of concept, database access had to be through the XSqda calls
which are inaccessible from within the engine. There are JDBC based
interfaces available (IscDbc for FB2 and InternalConnection), but Roman
rejected the idea of using JDBC for communications between the JVM and
the database engine.
I think moving to Java stored procedures is an excellent idea
(Netfrastructure has done exactly that from inception). I would like to
see Java as a near top priority for Firebird, but not at the expense of
breaking our product architecture.
>Hi Folks,The major hangup is an architecturally acceptable interface. The "proof
> A while ago I downloaded the proof of concept Firebird version
>which allowed Java stored procedures to be used. In the current
>versioning scheme, with Firebird 2, Vulcan, Firebird 3 which version
>is likely to have the Java integration.
>
> My testing of the test version was very positive and I am waiting
>in anticipation for it to make it into the main build.
>
>
>
of concept" breaks the product layering and is unimplementable in
Vulcan. The issue has to do with how SQL callbacks are performed. In
the proof of concept, database access had to be through the XSqda calls
which are inaccessible from within the engine. There are JDBC based
interfaces available (IscDbc for FB2 and InternalConnection), but Roman
rejected the idea of using JDBC for communications between the JVM and
the database engine.
I think moving to Java stored procedures is an excellent idea
(Netfrastructure has done exactly that from inception). I would like to
see Java as a near top priority for Firebird, but not at the expense of
breaking our product architecture.