Re: [boost] Interest in an ODBC library?

From: Corwin Joy (cjoy_at_[hidden])
Date: 2005-08-27 21:18:22

----- Original Message ----- 
From: "Sebastian Galkin" <paraseba_at_[hidden]>

> Maybe I'm missing something here :
>
>> Corwin Joy showed some example code that associates binding
>> conversion rules with types from DTL using RTTI names as the key
>> (snip)
>
> but are you using typeid(short).name() as a map key ? I think the
> standard doesn't guaranties uniqueness for the type_info::name.

This is what I did in DTL, but I don't advocate using RTTI for maintaining
the map of conversion rules here (though it worked well enough since every 
compiler I have seen will consistently return the same result when called on 
basic types).  I think it is
cleaner to simply have typed binding functions.  So what I would advocate
is a set of binding functions like this:

class Binding  {

public:

enum CType {};

enum DBType{};

PhysicalBufferInfo physical;

Binding operator>>(double &member) {

    CType = TargetType(member);

    DBType = DefaultDBType(member);

    physical = MakeBuffer(member);

    return *this;

}

};

class Bindings : map<tstring, Binding> {

// key = field name in the SQL table that the binding is associated with

//  tstring = wide or narrow string

}

So, as before this gets used to bind a field via

struct Employee {

string Name;

double Salary;

}

MakeBindings(Employee &Emp, Bindings &cols) {

col["Name"] >> Emp.Name;

col["Salary"] >> Emp.Salary;

}

Notice a couple things about how I propose to do the binding syntax:

1. The binding functions are directly declared and do not use a template 
syntax.  When I did DTL I first declared binding functions via a template 
syntax, but I found that compilers unevenly supported the "explicit" keyword 
and I would get unwanted coversions in which binding function was called.  I 
therefore think it is better to just declare the bindings explicitly.

2. The binding stores

    - the name of the bound field in the database,

    - the type of the C field that is being bound,

    - the type of the SQL field to bind to (this type will have to be 
further specialized by each type of DB layer, but maybe we could start with 
a set of generic types in a base class that can be further specialized - or 
perhaps we must template this on the driver type as well),

    - the address of where to write the data, and the size of the physical 
buffer that is available (size only comes into play if one wants to store 
fixed length strings - but there may be other things needed here as well).

3. The binding information is stored in an "enum" type fashion rather than 
templating on

the member being bound so that these bindings can be created "on-the-fly" at 
runtime

for queries which don't know the types at compile time.