Re: [boost] database library (was Report from Berlin C++ Standards Committee meeting)

From: Steve Hutton (shutton_at_[hidden])
Date: 2006-04-15 04:24:29

On 2006-04-15, Jeff Garland <jeff_at_[hidden]> wrote:
> On Fri, 14 Apr 2006 19:05:23 +0200, Maciej Sobczak wrote
>
> As much as I agree ODBC would be nice, I think the fact that there are 4
> bindings (pending reading the code) basically demonstrates that there is an
> appropriate abstraction layer to allow different databases to plug in.

Yes, I agree it shows the basic design is viable in terms of supporting
multiple databases.  We are however planning to do some internal
refactoring and restructuring in the next 2 weeks before the next
release.
>
>> > Error handling is the only thing that springs to mind looking at 
>> > the docs
>> 
>> Yes, that's one of the things that can be more elaborated. Currently,
>>  there's a single exception type (additionally specialized for 
>> Oracle) for reporting all errors.
>
> So this is where a critical question about goals needs to be answered. 
> Presumably the goal is to allow portability across the operating system
> dimension and NOT in the database dimension?  

Not exactly.  You should be able to write code which is portable
accross databases with SOCI, if you are careful to not use
vendor-specific extensions.  Which of course is a big if, but it
applies equally to most datbase libraries.  

> That is, if I write code to
> target Oracle it will work on Windows, Linux, etc -- everywhere the db vendor
> provides a driver.  However, there will be no guarantee that if I switch to
> Sybase my code written for Oracle will still work.  For example, the errors
> from Sybase might be different from Oracle.  Obviously if you use an ODBC
> driver you would have the same errors no matter the backend data store. Is
> this the vision?

We haven't really addressed this too much in SOCI yet, but I think there
should be SOCI exception types for basic classes of errors, plus
the native error codes, probably available via database-specific
exception subclasses.   This would give the user the chance to write
db agnostic code, or db specific code, as needed.
>
>> > I'd really like to encourage you'all to think about making a submission to 
>> > the committee.
>> 
>> Thank you very much for this encouragement.
>> As already said - we are looking for contributors with ODBC 
>> competences. Before having the ODBC backend it will be difficult to 
>> get wider acceptance than some of the competing libraries already have.
>
> If we are going to get this in the standard we don't have time to wait for
> widespread acceptence.  I think at a minimum we would need to get it to a
> Boost review...

Ok, makes sense.
>
>> > The only way 
>> > to make it happen is to have a plan and get organized over the next few 
>> > months to write up the proposal before the Oct meeting.  Even if you aren't 
>> > able to come to Portland to present the proposal one of us that is there can 
>> > help with that aspect.
>> 
>> Thanks again. :)
>
> Well, I wouldn't thank me yet ;-) What I'm not so subtley trying to do is talk
> you and everyone else that has an interest in seeing a standard way to access
> database in C++ to cancel their weekend parties, stay up a couple hours later
> a night, etc to pitch in an make this happen.  There's really only about 4
> months left -- it's really a very short time...

I believe Maciej is going on holiday now...shortly after he returns
(25th of April) we will release SOCI 2.1.  At that point I think we
can gather feedback to put together a TODO list needed for a boost
submission and get into the review queue.

Steve