Roman Rokytskyy wrote:

>
>
>>We will continue to support the existing external API, probably
>>forever. But as an API, it stinks. SQLDAs and SQLCODE codes are a
>>miserable way to write code. It wasn't even particularly nice in
>>1986 when I borrowed it from DB2. And it hasn't gotten any better.
>>A nice, simple, OO interface that significantly reduces the cost of
>>the various transmission layers is the way to go.
>>
>>
>
>Which would require then implementing another JayBird - one for old
>ugly API (is already there) and one for nice OO API. Now, if we
>consider new wire protocol implementation and if conceptually it will
>not be based on either OO API or "ugly"-API, we get the third JayBird
>implementation. Not that I am very happy with it. But even if we
>ignore my happiness, this path requires a lot of work and time.
>
>

That's fine. You can use any API that we support. Nobody is suggesting
that you change. But please remember that this isn't what we're talking
about. The issue at hand is how something invoked from within the
engine gets database access. I hope you weren't planning to loop around
the external interface.

>
>
>>It will probably track JDBC, but there isn't much in JDBC 3.0 or 4.0
>>that is particularly important or even interesting.
>>
>>
>
>Exactly, all that is mostly not so important things, but they
>constitute the JDBC X.x compatibility. It does not matter if we think
>that the feature is important or not, matters what other think of it
>(and in most cases this is all about a checked checkbox in the feature
>list).
>
>

No, the goal is not to claim JDBC compatibility. The goal is to provide
a robust, simple, convenient database API to client programs written in
OO languages like Delphi and C++.

>As an example take a scrollable and updatable result set that is not
>supported by Firebird. This type of result set is expected by the Sun
>RowSet implementation. The RowSet API is used now in many different
>components/applications. It was not possible to use them with Firebird
>till JayBird 2.0 which emulates them by caching all the stuff in
>memory. So, the same feature has to be emulated there too.
>
>

I doubt that will ever be implemented inside the engine or server. It
is a client side service that should be layered on the published
database API. We may want to make it part of the client library, but it
isn't a candidate for inclusion in the engine. It certainly is not
something we would ever want to support in external database procedures.

>Since we are going to support old ugly API on top of nice OO API (it
>will be on top, isn't it), why cannot we export the same old ugly API
>for those that want to use it for external procedures, basically those
>that already have database access components and want to use them to
>access the engine?
>
>

The simple and definitive reason is that the "old ugly" API doesn't
exist inside the engine. Between Interbase 4 and Firebird 2.0 the DSQL
implementation is in the Y-valve, not the engine. While it would be
possible to export the BLR calls, I don't think that will meet your
needs. There is simple no architecturally sanctioned mechanism for a
engine called service to use SQL before Vulcan. You could trying
breaking the layering by reversing engineering the Y-valve and
attempting to traverse its data structures to find the appropriate
handles, but this is unsupportable, at best.

I'd be happy to explain in greater detail, but I'm afraid you will find
that his is a dead end.

>But again, we moved away from the document. It was not about the
>engine API that is passed to the external procedure (that was supposed
>to be separate discussion), but about the API that external procedure
>has to implement. You suggest to use existing ResultSet class instead
>of the one suggested in the document. Right? Now the questions to your
>ResultSet concept:
>
>- are strings unicode? if not, how does the code that uses ResultSet
>get information about the character set? note that XSQLVAR contains it
>already.
>
>

In JDBC, they're Unicode. In the IscDbc interface, they should be UTF-8.

>- how blobs are passed - by ID or as a stream? if former, are blob
>routines part of the result set interface? if latter, how does
>application know the charset for clobs? note, this information is
>available in XSQLVAR.
>
>

ResultSet::getBlob, ResultSet::getClob, ResultSet::getBytes,
ResultSet::getString. (You could have looked yourself, you know).

>- are timezones handled by the result set for timestamp? if not, in
>which timezone they operate and how to get that timezone? note, we
>have default timezone for JVM, but not for the server.
>
>

The internal SQL use the same rules as other requests.

>- does ResultSet perform the type conversion, e.g. can we call
>ResultSet.getString(int) method for an INTEGER field?
>
>

Of course!


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376