At 01:51 PM 5/31/00 -0700, Mike Grogan wrote:

I hope you don't mind if I copy the InterBase architecture list.

>
>Looks fine, but to protect my whining rights I'd better come up with some
>comments/questions.
>
>* I don't see placeholders in the interfaces for methods needed to
>implement some ODBC2/JDBC2 features I hope we get to see in the near future
>(scrollable cursors, updatable recordsets.) Maybe designing the interfaces
>to support these features and having the implementations fail would
>encourage people to help fill in the holes.

Good point. I've added a method "int objectVersion()" to each of
the classes to allow for extensibility (all are initially 1). We
just need to document which additional methods are added each time
the version number is incremented.

I should probably bite the bullet and add all of the JDBC 2 methods
right now and be done with it.

>* execute() executeQuery() executeUpdate() -- How do you know which to
>call if you are implementing a programming API like ADO or ODBC and have a
>method like SQLExecDirect that can be passed an arbitrary SQL string. After
>preparing the statement you can check isc_dsql_sql_info(), but I don't see
>this exposed in PreparedStatement class. Maybe there should be a member in
>StatementMetaData exposing query type.

execute() is the guy to call when you don't know what you're doing.
You then call Statement::getMoreResults() to get the next result
and either Statement::getResultSet() or Statement::getUpdateCount()
to find out what you got (getResultSet return NULL is the statement
was an update; getUpdateCount returns -1 is the statement was a
query).

>* There is no class equivalent to JDBC CallableStatement. Is there a
>way to retrieve out-parameters? Seems like StatementMetaData also needs a
>member exposing parameter direction.

Oops. Need to add CallableStatement asap.

>* Is the {? = call foo(?,...,?)} syntax for calling procedures
>supported inside this class library or the SQL engine itself? If not, does
>the ODBC driver support it? (I need this pretty badly)

Yes, it will be supported in CallableStatement. And since you want
it, it will be showing up sooner or later.

>* What is a result list?

The output of a text search operation. Unrecognized by anything
else in the world other than another of my projects from which I
snatched heaps of code. Since I'm defining the interface by
enlightened fiat, I add this hack as a point of personal privilege.
You can expect InterBase to return a SQLException of not_yet_implemented.

>* What is the philosophy of the object lifetime management. In other
>words, what is the relationship between the lifetime of an object in the
>class library and the "openness" of the database object it wraps. In the
>object model I'm used to (ADO) the database objects wrapped by the C++
>objects are not always open and method calls requiring database connection
>fail nicely if they are not. The dtors of the C++ objects do implicit
>Close's on the database objects they wrap and Connection.Close does an
>implicit close on each Recordset associated with it. Closing an object
>never has any effect on the object's lifetime. Is the behavior here
>different in a major way? Why is AddRef exposed? I do see the need for
>Release.

AddRef is added as a courtesy for client software for exactly the same
reason that COM exports AddRef. The last release closes the object
(and associated resources) then deleted the object. Close() short
circuits the use count mechanism to compatiblity (such as it is) with
JDBC. Think I should flush it?

Note that, in general, I haven't exposed any destructors (exception
is Properties, which I will shortly change).

>* As you point out (regarding multiple transactions) the API's don't
>expose all the functionality in the existing underlying isc_* api's. In the
>implementation is there a sneaky way to get direct access to the database
>handles? Seems that they should at least be declared protected so that an
>enterprising programmer with access to the sources has a shot at deriving
>subclasses that extend the functionality without hacking up the base
>classes.
>

In theory the client program doesn't have access to the implementation
behind abstract class, so nothing in any object is visible. OK, the
source is open, a guy can cheat until he gets burned. In theory, no,
the handle is neither visible nor accessable. For the sake of purity
and light, no back doors. If we can support something through the
proper interface, we'll fix the interface rather than polluting
the specification.

I have already been compelled by irrefutable argument to add
Connection::clone() to handle multiple transaction. The implementation
implications are obvious (to the most naieve of observers...).

>
>Overall, these look like nice clean interfaces to program to. Seems wierd
>to implement untidy, low-level things like ODBC drivers and OLEDB providers
>on top of them, but I see the value of having a unified body of native code
>that can be used to implement methods in every script language in the world.
>

Actually, about 80% of the total ODBC driver effort is in the IscDbc
layer (and all of the fun part). If we get this puppy right, writing
all of the ughly alphabet soup access methods should be a snap. It
may be even better, however. Once somebody writes a JDBC wrapper for
an API, the generic Odbc/Jdbc ODBC driver will automatically work. When
some (else!) writes an OLEDB provider, ditto.

If Sun doesn't completely screw up Jdbc, I think we've got something
we can live with for a long time.

Thanks for the comments. Back to Linux.

Jim Starkey