Subject | Re: [Firebird-Architect] Re: Java Stored Procedures |
---|---|
Author | Jim Starkey |
Post date | 2005-10-20T19:28:03Z |
Roman Rokytskyy wrote:
available in Firebird can be captured in JDBC 1.2. It can be extended,
but it doesn't have to be.
language processors. What does that have to do with IBX, et al?
backported to Firebird 1.0 or 1.5, so I don't see your point.
manner. Just get used to that idea.
architecture of Firebird so you don't have to change your code. Is that
the only real issue here?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376
>Maybe... but only if that someone would like to stay with JDBC 1.2,No, it doesn't mean that. It only means that the functionality
>but considering JDBC 4.0 to be released next year... I know how much
>code in JayBird is responsible for JDBC compatibility, and what does
>it mean to be JDBC-compatible.
>
>
available in Firebird can be captured in JDBC 1.2. It can be extended,
but it doesn't have to be.
>And you did not answer how tiny that layer would be for otherHuh? We were talking about an internal engine API exportable to
>components, like IBX/FIB/IBO for those willing to code in Delphi, or
>.Net with their ADO component model.
>
>
language processors. What does that have to do with IBX, et al?
>Nobody has suggested that the load language processor interface be
>
>And regarding to the calls, it is definitely more informational than
>version strings. Unfortunately you cannot rewind the history and add
>them to Firebird 1.0 and 1.5, so version string have to be supported.
>
>
backported to Firebird 1.0 or 1.5, so I don't see your point.
>Roman, the external API doesn't exist inside the engine in a supportable
>
>As you suggested, the "API" object will be passed into the call. In
>your case its InternalConnection, in case of ISC API some db handle
>and tr handle would be enough.
>
>
manner. Just get used to that idea.
>Let us get this straight. You want to screw up the internal
>
>>The problem is that the current ISC API is soon to be relegated to a
>>client side layer on top of a more efficient API. Much of what you
>>consider the current API disappears inside of the client side
>>Y-valve and isn't supported in the engine at all. Building in the
>>old SQLDA-based interface makes no sense at all.
>>
>>
>
>Well. When it disappers, I will adopt a new API, but so far I do not
>feel to be an early adopter for something that would need complete
>rewrite of JayBird.
>
>
architecture of Firebird so you don't have to change your code. Is that
the only real issue here?
--
Jim Starkey
Netfrastructure, Inc.
978 526-1376