Re: [boost] Interest in an ODBC library?

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2005-08-26 10:22:47

> On Behalf Of Corwin Joy
 
> I guess you could do this in the bindings.  I'm not sure how you would
get
> compile time checks that you are assigning an illegal value to a field
if
> you
> just expose a collection of boost::variant fields tho'.

Unfortunately, there really isn't any way to guarantee at compile time
what the data types in a database will be at run time.

> Actually if you re-read my earlier post my point is exactly the
reverse.
> Fixed length strings are easy to support from an implementation point
of
> view,
> it is arbitrary length strings that are hard. 

I guess I'm still thinking of it from an interface point of view.  Even
if you're dealing in fixed length strings in the implementation, you can
still return arbitrary length strings to the user.  SQLPutData won't be
a problem since we're using read-only record sets.

> 2. More problematic, if you call SQLGetData  and SQLPutData on a
column
> then
> ODBC says it may not be supported unless that string column comes
last.

That's odd.  I've never used a native interface that cared about column
order.
 
> I'm not saying that you should default construct this inside private
class
> members,
> but what I am saying is that you will need to allow it to be
overriden.
> I'll give a
> couple examples:
> 1. In microsoft access there are two kinds of text fields, text and
memo.
> text can be up to 255 bytes long, memo can be much larger (I think up
to
> 4k).
> When you bind a text column, you have to specify a SQL column length.
> If you specify >255 for a text column you will get an error.
> If you specify 255 for a memo column you will get truncated.
> When the user binds a std::string you don't know what kind of SQL type
> they
> are binding to.

The interface only provides the ability to read from record sets, which
is all some native interfaces allow.  When returning std::string, it
doesn't matter whether the source was memo or not.

Speaking of Access; I'm pretty familiar with it too.  We had been using
it for 5 or 6 years via DAO and just finished converting our entire
system to PostgreSQL.  I didn't know about memo fields when we first set
up our access databases, and the 255 byte limit was a major source of
pain for us.  Now all our text fields are unbounded (and per PostgreSQL
documentation suffer no performance penalty).  I think it's just common
wisdom in programming that if you put an arbitrary size limitation on
something you're asking for trouble, which is part of the reason I'm not
too worried about fixed length strings.

> Anyway, not having a class to hold the source SQL column type is just
> wrong
> IMO since
> there are all kinds of conversion rules that may be desired and the
> default
> may not be the
> right one and have to be overriden.

I'm still thinking about the interface.  The implementation will
certainly need no hang on to the SQL column type.  It will be the
implementation's job to choose the right conversion.

> Yes, definitely they should be hidden as private members, I was just
> pointing
> out that this association needs to be made.

I think we're saying the same thing then.  We definitely can't convert
from database type to C++ type without this information.  I was thinking
that it would live in the implementations: Boost.Database.PostgreSQL,
Boost.Database.MySQL, etc... and not in the interface.