On 24 February 2013 20:26, vaclav <[email protected]> wrote:
> Just one more thing to consider. Sometimes we need not only a better way
> to specify session options before calling "connect", but also an interface
> for asking what session options are actually in use.
> [...]
Generally, it is a good idea and unified access to session environment
properties would be nice.
This is related to context/environment used by a user to pass configuration
settings to session constructor.
I see two types of parameters in such enviornment
1. SOCI-known parameters
They can be both, SOCI-specific and database-specific, but they all are
recognised by SOCI. It means:
- SOCI uses some of them directly to configure itself
- SOCI passes some of them to backends and further down to database API
The basic assumption is:
if SOCI knows a parameter, it knows what to do with it,
how to use it or how to pass it to lower level API (through backend,
so a particular backend knows what to do with it), etc.
2. SOCI-unknown parameters
They are those parameters that SOCI neither knows nor cares about.
In order to support arbitrary database-specific parameters,
SOCI must assume that means to set/get parameters do exist
and are provided by low-level client API used by (each?) backend.
Vadim's started discussion related to the 1st category.
There is no problem to extend it for the 2nd category too.
We just need to deal with the very typical challenge in SOCI [***]:
- does every database API we use provide access to such client environment?
- how to deal with diversity of features supported
- do we want to map database-specific property to common set
Examples;
For single backend, i.e. Oracle, it would be easy-peasy:
soci::session s;
s.get_parameter(CI_ATTR_ENV_CHARSET_ID)
but what to do for PostgreSQL?
s.get_parameter(CI_ATTR_ENV_CHARSET_ID)
We have to map CI_ATTR_ENV_CHARSET_ID identifier to
a a function call, PQclientEncoding()
Likely, we will want a form of mapping
// enum or string names, it's just implementation detail,
// irrelevant for now
namespace soci {
enum session_properties { client_encoding };
};
and each backend maps SOCI-defined client_encoding to
corresponding low-level API features.
Next challenge, how to interpret input/output?
Some backends will return their own specific integer IDs,
some will take/return strings (e.g. ISO aliases).
Are we going to compile a mappings for each property for each backend?
Also, if I call
s.set_parameter(client_encoding)
and backend behind s does not support access to environment
properties, do we throw or no-op?
[***] This issue is of very similar nature to the one about support of
conversions for all C++ integer types; or simple get_affected_rows() support.
Just to make it clear, I don't express my objections.
I'm just being careful and not not keen in jumping to code that
feature straight away :)
I guess, we can work it out in two steps;
- continue what Vadim's started, and
implement 1 for SOCI-known parameters
- then we can move to 2. and figure out how to support such arbitrary
properties.
> Here is a low-level SQL Oracle driver for Python, like a backend in SOCI.
> It provides backend-specific interface for retrieval of such session
> parameters.
> http://cx-oracle.sourceforge.net/html/connection.html#Connection.encoding
Good example of use of OCINlsNumericInfoGet and other APIs for Oracle.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
