Re: [boost] SOCI 2.2.0 - The C++ Database Access Library

From: Jarrad Waterloo (jwaterloo_at_[hidden])
Date: 2006-12-06 09:45:15

>> 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).

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.

>> 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?

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