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