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! Jeff