| Subject | Re: New API -- Request for Comments |
|---|---|
| Author | Olivier Mascia |
| Post date | 2000-05-30T21:31:09Z |
Jim,
[ Just some preliminary thoughts, because I'm left with only one work day
before leaving for an extended week-end. I'll comment as much as possible
next week. ]
I think you know I really like the general design idea behind this new API.
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 ?
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 ?
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.
D. getByte, getInteger, and the like : how can I check if the field is SQL
NULL or actually returned a data ?
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.
I can't comment on class DatabaseMetaData, I'm JDBC deficient, for now.
Olivier Mascia
om@...
[ Just some preliminary thoughts, because I'm left with only one work day
before leaving for an extended week-end. I'll comment as much as possible
next week. ]
I think you know I really like the general design idea behind this new API.
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 ?
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 ?
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.
D. getByte, getInteger, and the like : how can I check if the field is SQL
NULL or actually returned a data ?
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.
I can't comment on class DatabaseMetaData, I'm JDBC deficient, for now.
Olivier Mascia
om@...
> Message: 23
> Date: Tue, 30 May 2000 12:21:58 -0400
> From: Jim Starkey <jas@...>
> Subject: New API -- Request for Comments
>
> Below is a sample program and formal specification of the C++
> Jdbc interface that I'm developing as part of the Odbc implementation.
> The sample program should be more or less self-explanatory; if not,
> please don't hesitate to request a clarification.
>
> .... >>> cut for saving some electrons <<< .....
>
> Jim Starkey
>