Jarrad Waterloo wrote:
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, password and ... that gets mapped automatically into database specific parameter names.
How would you like to use it?
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?
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. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/