At 11:31 PM 5/30/00 +0200, Olivier Mascia wrote:

>

Before I get into the substance, let me thank you for the quick review.
Things are almost always a great deal better if they kicked around before
they're "chilled."

>
>I think you know I really like the general design idea behind this new API.
>

None of the existing interfaces (in my ever-humble opinion) are sufficiently
easy to use and none lend themselves well to object oriented languages.
The current InterBase API has two independent roots. The framework
is BLR based OSRI/DSRI with an early DB2 DSQL grafted on. The DSQL
interface has been extended a few times, not necessarily gracefully.
The resulting API is not pleasant to easy to code against, and is
nasty to wrap for object oriented languages. ODBC is a disgusting
mess of an API -- the calls lack typing, cannot be described in a
strongly typed language, and requires vastly more code to use than
is reasonable. The official SQL API is what one can reasonably
expect from a 10 year long committee approach.

I would like a interface that:

a. Is pure interface definition (no driver manager, thank you).
b. Is defined in terms of objects.
c. Does not require external data structures to use
d. Signal exceptions (check status codes is for the birds)
e. Has been blessed by adults somewhere (believe it or not,
even the BBW doesn't like to reinvent the wheel).
f. Can support an ODBC driver (draining the swamp...)
g. Is reasonably language independent (semantic, not necessary
syntax).

Jdbc, I think, is good enough.

>A. Why should we really need a driverManager à la JDBC ? I'm sure I miss
>some big point here. Isn't this API supposed to "connect" / be implemented
>by relying on the existing C-API ?
>

We don't. Unlike ODBC, which is an intermediary for all calls, Jdbc's
driver manager exists only to provide polite introductions between
a client and a driver. The client takes directly to the Connection
object and his henchmen leaving the driver manager in the dust.

For the time being, I'm not using a driver manager at all. The
mechanism to connect to a driver is to load the driver, lookup
the entrypoint "checkConnection()" and call it.

If I ever learn to like XML, I'll make a driver manager use it
for something.

>B. I do not like the concept of "multiple transactions" means "multiple
>attachments". Even if this is needed to be "JDBC"-like. I agree a kind of
>attachment handle sharing through a sort of clone() method gives practically
>the same kind of results, but I think some other object is required to
>encapsulate the transaction. IMHO, it's cleaner and at least it gives a
>coherent solution to handle distributed transactions. With the current
>proposal, how would you write a sample program connecting to two databases
>and starting a two-phase commit transaction to update things in both
>databases ?
>

Yeah. I tend to agree with you. If Sun had asked my opinion, Jdbc
would have been a little different.

That said, a Connection is, more or less, a transaction. Adding
Connection::clone() would give a perfectly serviceable transaction
capable of sharing the database connection (for the one and only
database that supports multiple transaction per process).

Some thought definitely needs to be given for a two phase commit.
Complicating the issue is that there are two competing standards
to cross subsystem two phase commits. Even worse, the better of
the two is Microsoft's.

I did a little design work a year ago on the problem that I should
dig up. I think it important that the hooks be good enough to
plug into industry standard solutions that inventing something
not quite good enough.

>C. "Connection *connection = createConnection();"
>So you prefer to ban things like "Connection* connection = new
>Connection();" ?
>Or "Connection connection;" ?
>Anyway, we at least require some releaseConnection() or freeConnection() to
>free resources, then.
>

First, that won't compile because Connection is an abstract class --
it is a pure interface with no code behind it. The actual Connection
object will be a subclass of Connection substantiated by a Jdbc
driver/subsystem. Since the client program can't be compiled against
the real thing, it has to call somebody to create the actual object.

>D. getByte, getInteger, and the like : how can I check if the field is SQL
>NULL or actually returned a data ?
>

ResultSet::wasNull() returns true/false.

>E. Naming convention : types like Blob, Int, Long, and so on may too easily
>conflict with other unrelated classes when used in a quite large project.
>Maybe some common prefix to each class name, type name. Or rely on the C++
>namespaces.
>

Tell me about. I just spent a couple of dreadful days cleaning the
interfaces out of existing implementation code.

But, this really isn't a problem since the #include "Connection.h" can
reside inside a namespace within the client code. We really don't
have to solve this problem.

>I can't comment on class DatabaseMetaData, I'm JDBC deficient, for now.
>

An earlier draft of Jdbc had a single function to indicate Jdbc
compliance -- boolean valued. It seems to have gotten lost. Problem
went with the smart JavaSoft guys when they joined the real world to
get rich.


Jim Starkey