Re: [boost] SOCI 2.2.0 - The C++ Database Access Library

From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2006-12-05 09:55:50

Maciej Sobczak <prog <at> msobczak.com> writes:
[...]
> I would like to stress that the ODBC support was our important milestone
> that now allows us to claim a quite extensive coverage of existing 
> database technologies. With this in mind, SOCI becomes even more serious 
> and our roadmap for the nearest future is to bring the library to the 
> state that will make it a valid candidate for inclusion into Boost. We 
> will therefore welcome your guidance and suggestions w.r.t. Boost 
> compliance.
>
> Note that up to this release, the library was deliberately developed 
> without any external dependencies, so there are obviously wide areas 
> where Boost might be applied within the library itself (example: 
> intrusive pointers to manage some refcounted objects). This is easy.
> The more difficult part is the library interface and its general philosophy.

The last time this topic was discussed, it was hoped that the outcome could be
a proposal to be included in the standard committee's TR2. Even though that
deadline has passed proposing a library for inclusion in the standard is
certainly a worthwhile objective; is that something you want to pursue with
SOCI? I'm asking because I think that the answer may influence interface
choices, e.g. to simplify support for single backend implementations or to
limit use of Boost libraries to those accepted in the TR's.

As I already mentioned in a previous discussion I believe that a distinction
should be introduced between core DB access functionality and higher
abstractions such as the object/relational mapping, especially in view of a
possible standard submission.

Another issue I consider worth discussing is how dynamic should the choice of
backend be. While I think that a plugin oriented architecture would be
overkill, the degree of independence from the underlying technology provided
by libraries such as Borland's VCL is convenient. This would probably mean
adding a registration based mechanism to the way backends are currently
selected in SOCI. On the other hand I don't think anybody wants something as
complicated as ODBC's driver based approach.

Diagnostics is another area that deserves consideration. In a way failures are
easy to handle, because you can always, or rather should always, throw
exceptions. On the other hand I don't think there's a proven best way for
providing non terminating, informative diagnostics. Is it possible to devise a
unified approach that combines general backend information to details on data
retrieval results (eg. nulls, truncation, etc.)?. This is directly connected to
value representation issues, like the use of Boost.Optional to represent nulls,
etc.

I'll leave more specific API related issues for later.

Cheers,
Nicola Musatti