Re: [boost] Interest in an ODBC library?

From: Brian Braatz (brianb_at_[hidden])
Date: 2005-07-27 17:32:20

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Hajo Kirchhoff
> Hi,
> 
> > What I don't like in your approach is that you require that there is
a
> > type (my_table above) for each different rowset traversal "profile"
-
> 
> I don't. This is not required, this is merely an example. For small
> tables and simple queries its the fastest way. But not the only way.
> 
> > interested in only some of the columns - from 2 to 5, typically. Do
you
> > require that the application always retrieves all columns?
> 
> Absolutely not.
> 
> odbc::statement s("SELECT column1,column2,etc... FROM ...");
> 
> is supported of course.
> 
> > Just imagine a single table with 4 columns - there are 15 different
> > subsets of columns there (not counting the queries with no columns).
> 
> Also there does not have to be a 1:1 relationship between the members
in
> my_table and the columns of the table. Subsets are fine. In fact, if
you
> have a table with 150 columns and want to select only a subset of
> columns, you have a couple of options with my approach.
> 
> a) write a struct ... containing only a few member variables for those
> columns you want to select.
> 
> b) use individual variables to bind them.
> 
> c) all of the above
> 
> Another example:
> odbc::statement s("SELECT one([bindto]a), two([bindto b), sixteen,
> seventeen, eighteen FROM huge_table");
> long a, b;
> struct some_struct;	// has members m_sixteen, ...
> some_struct data;
> 
> s.bind(a, "a");		// bind variable a to column one
> s.bind(b, "b");		// bind variable b to column b
> 	// bind all member variables of 'data' to columns
> 	// of the same name ... if they exist
> s.bind(data);
> 
> > You does your approach scale in this aspect?
> 
> It does.

I do not see that it does.

At a minimum, you need to support working like a dynamic ADO recordset
does.

that being, I can issue a call, and retrieve back the data, but I do NOT
have priori knowledge of the types that is going to contain.

I offer the following high level design thoughts-

you split the lib into a few pieces:

1- Get the data from the data base and stream it into X
2- a stock form of "X" (like the table you described)
3- Helpers for binding

if you built the thing that way, then it will be usable by those of us
out there who have large bodies of code relying on things like ADO
recordsets. I would love to replace the recordsets, but I need to be
able to selectively use pieces of your library and I need to have a
usage model that is similar. 

Thanks,

Brian