Boost logo

Boost :

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-12-05 09:21:31

Maciej Sobczak wrote:
> Jeff Garland wrote:
>> - refactor src tree to be boost-like (boost tree, finer grained headers/cpp files)
> Yes, the code might benefit from some work in this area. Still, we would
> like to limit the number of "entry points" for final users, in the sense
> that for example it should be enough to do this:
> #include "soci.h"
> #include "soci-oracle.h"
> (names don't matter)
> to be able to play with Oracle. This way of thinking has led us to
> single soci.h header, but I agree that it would benefit from some
> refactoring.
> The backends have already very fine-grained file structure.

Ok, well there's no reason you can't have both. The soci.h can just include
all the fine-grained headers.

>> - write some tests (maybe I'm just missing them in the distro)?
> Looks like. :-)
> src/core/test/common-tests.h
> src/backends/DBNAME/test/test-DBNAME.cpp
> For each server, the above pair provides a comprehensive set of tests
> (they are automatically built together with the library; just run them).
> The common-tests.h file contains common tests cases that are used for
> all servers.

Oh, that's good. The tree refactoring would make the tests more obvious.

>> - full reference docs
> doc/reference.html (for client interface)
> doc/backends.html (for authors of new backends)
> doc/backends/DBNAME.html (for server-specific issues)
> Plus subject-by-subject tutorial (start from doc/index.html).
> Anything missing?

header by header, class by class documentation for all interface classes. I
see the reference page, but I suspect that isn't really everything the user
might use.

>> Note that I expect the review for SOCI to be tough because it's a fairly large
>> and complex domain/lib. So we ought to ask the review manager for a longer
>> review right up front.
> That's reasonable.

Seems like you might want to get in the queue now...

>>> The more difficult part is the library interface and its general philosophy.
>> Not sure I understand the problem here...
> The SOCI library stands out a bit in the crowd thanks to its basic
> interfacing assumptions. Some users love it exactly because of its
> interface and some others hate it exactly for the same reason.
> This already proved to be a recipe for heat generator. ;-)

Hmm, I guess my memory of this is short. I can't do anything at the moment
since I'm already over committed, but I'll try to do an informal review over
the holidays to ferret out any issues.

BTW, one thing I can imagine being discussed is the library name. SOCI seems
a little out of date at this point. As you make the transition to Boost maybe
it should be DAL (database access library) or some other more general name.

Thx for your efforts!


Boost list run by bdawes at, gregod at, cpdaniel at, john at