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?