> >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.
>

Understood.

>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.
>

Okay. For now, I only suggest that the connection.clone() method be
implemented from day one of your first release. Even if it is of no use for
ODBC implementation, it is really important for other kind of application
softwares written with your API.

> >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.

Good point and design.

> >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.
>

So I have to call wasNull() after each get() ?
And that call to wasNull() gives me an answer related to the previous get()
call ?
Sounds a little bit tricky, isn't it ?

> >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.
>

Agreed.

> >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
>

Olivier Mascia
om@...