Re: [boost] Interest in an ODBC library?

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2005-08-18 10:45:56

> On Behalf Of Jonathan Wakely
> 
> Caleb Epstein wrote:
> 
> > I think the ability to detect NULL values for columns is a pretty
> > important one in any database interface.  Boost.Optional sounds like
> > the perfect solution from a design perspective, but might hurt
> > performance-wise.  What if there were a method like bool
row::is_null
> > (unsigned int index)?

Generally, I'd lean towards cleaner interface until a performance
problem is proven.  Chances are any time spent dealing with optional<>s
is going to be dwarfed by the database operations.

> I think it's reasonable to have to ask whether it's NULL before
fetching
> the value, rather than using optional.

This is exactly the situation Boost.Optional was designed for.
 
> Some queries won't return NULLs, either because the column definition
is
> NOT NULL or because the query specified "IFNULL(..., ...)" so the user
is
> the best qualified to know whether it is necessary to test for NULL.

The user's program might not be the only one writing to the database
though.  It's nice to be able to have a way to provide a default
automatically.  Maybe:

   template <typename T> T
   get(const std::string& field_name, T default_) const;

so you could call it like:

   i->get("field", 0);

instead of

   i->get<int>("field");

> If they call get() then the library can assume they know there's a
> non-NULL value there to get() and not worry about handling a NULL.

Still, I hate to have an interface where the user can easily forget to
call is_null() and calling get() can blow up long after the user's code
has been though testing.  When you return an optional<> it's clear that
you need to check it.

I think the concrete interface can provide:

   1) a version of get that returns an optional
   2) is_null(unsigned int index)
   3) a version of get converting nulls to defaults

all by changing the abstract_row::get to return an optional<field>.  If
this proves to be a performance issue we can optimize the abstract
interface with an is_null() function leaving the concrete user interface
unchanged.

On another topic, what do you think of the types included in the field
variant?  What important types are missing?  Should we try to include
all types our users could need or just the most common ones and an easy
way for the users to change it?