I know the review hasn't even been requested yet but here are some interface suggestions.
1) Session constructor that takes a std::map<basic_string<>, basic_string<>> as the second parameter instead of "service=orcl user=scott password=tiger".
I'm not convinced. First of all, std::map is nothing special. Why not unordered_map? It would be probably better to provide a dedicated helper function that takes the map and build the string from it. Second, some servers don't expect key=value pairs, there might be something entirely different (for example, SQLite3 expects just a filename).
2) With respect to the first request, standard names for username,
Std::map was just an example. Whether it is map, unordered_map, vector of name value tuples, it is all the same to me as an object oriented consistent approach to access and build the parameters for a session. This could even be a helper class though I would imagine that the api layer itself might like it in a structured approach so that it wouldn't have to parse it in order to format it correctly. Then again I am a user and not library implementer and just looking for this functionality which is also commonly found in ODBC?,OLEDB,ADO,JDBC and ADO.NET. password
and ... that gets mapped automatically into database specific parameter names.
How would you like to use it?
If a lot of databases has a parameter name that serve the same purpose of a user name it would be nice if each implementation could recognize some standard that you set up that the user can specify 'username' and the implementer will treat it like or translate into their specific terminology 'user name', 'user', 'user id' ...
3) CLOB ie. Ntext that automatically gets extracted as a string field. 4) CLOB class to complement your Blob class
Yes, these two are considered.
5) A STL compatiple stream interface to your Blob.
It's not necessarily portable. Various servers differ widely in how they approach BLOB as a concept. The whole idea needs more specs - how should the streaming operation relate to transactions, for example?
With respect to transactions, however your current Blob implementation works or it can be modeled after how other standard are designed. It may not even matter in many cases since one most common scenario is to write out the whole thing at construction and read out the whole thing multiple times during the lifetime of the record. The most important thing is having a consistent interface that play nicely with STL and other STL compatible streams created with Boost stream libraries.
6) Official support for the wstring type
Indeed, this seems to be important.
7) A place to register data providers and to choose one programmatically so that ones code can be configured to use a different database without recompiling.
In a sense you can do this with SOCI. Backends are linked-in (so there is no run-time "registration") and the session is started with polymorphic reference to the backend factory. If you expect entirely out-of-program registration/selection support, you have it in the form of ODBC.
ODBC is a important and necessary bridge to the past to get new users on board however as you the library move forward users prefer native libraries written within your api as there are fewer layers (performance), potentially more functionality and fewer points of failure. As such SOCI will need to be able to do mostly anything ODBC can do but better. This is just one of them. Business Requirement: User wants to write and compile their program and have it work with any database. Business Requirement: Database provider wants SOCI to do as much work and provide as much requirements as possible so the amount of code they have to write is minimal. Business Requirement: User eventually wants simple easy to create provider api so that they can create a SOCI compliant proxy around their data sources so that that other api's that know SOCI will work with it. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost