Re: More on SrPersist buffers

Subject: Re: More on SrPersist buffers
From: Jonathan Edwards (edwards@intranet.com)
Date: Wed Dec 05 2001 - 17:43:31 EST

You don't have to parse the SQL or query the DB metadata. You ask ODBC for
the result set's metadata (SQLDescribeCol). Works for any kind of query or
result set or driver. This is the sort of problem ODBC was meant to solve.

The wrappers on all the ODBC functions that associate a result set with a
statement have to clean up buffers from the previous result set. The
wrappers for all ODBC functions that free handles also have to shadow ODBC's
state.

I guess my point is that it is possible to implement a Scheme API to ODBC
that operates at the same conceptual level (feed in your own SQL statements)
without revealing C semantics (memory model of values, explicit memory
management). 

--
Jonathan

Paul Steckler wrote:

> In order to allocate buffers when a statement is prepared, you'd have to
>
>  - parse the SQL to know how many columns there will be
>     in the result set (it might be `*', meaning all columns)
>  - consult the database to obtain column metadata
>
> That's possible, of course, but more than I think SrPersist should do.
> It's also harder than it sounds, because drivers are allowed to accept
> SQL that's arbitrarily more complex than the ODBC Minimum Grammar.
> Result sets might be created with queries that are not the usual SELECT
> ... FROM ... boilerplate.
>
> Another problem is that certain ODBC procedures can free statement
> handles implicitly.
>
> Yet another, perhaps bigger problem is that result sets can be
> associated with statement handles without even running SQL queries.  For
> example, there are ODBC/SrPersist procedures called `foreign-keys' and
> `column-privileges' that do just that.  There are others in this
> category.  And for the meta-data result sets created by those
> procedures, the number of columns varies by the driver used.  How do you
> allocate buffers when these procedures are used?
>
> -- Paul
>
> -----Original Message-----
> From: Jonathan Edwards [mailto:edwards@intranet.com]
> Sent: Wednesday, December 05, 2001 3:57 PM
> To: steck@ccs.neu.edu
> Subject: Re: More on SrPersist buffers
>
> I still think you could completely encapsulate these buffers inside a
> statement object (along with its handle). Have them automatically
> allocated and bound when a statement is prepared, and then free them in
> a statement-close function, which also unbinds them and free's the
> statement handle. A GC of the statement object should close it.

This archive was generated by hypermail 2b28 : Wed Dec 05 2001 - 18:37:06 EST