On 31 January 2013 21:11, Vadim Zeitlin <[email protected]> wrote: > At least under Windows, it's common for the ODBC driver to show a dialog > box to the user asking to enter the missing information when connecting via > a predefined DSN. Typically, the password is not stored in the DSN, where > it could be easily seen, but entered during connection time in this dialog > box. > > [...] > So I see several alternatives, let me list them here > with their pros and cons: > > 0. Just replace the hard-coded SQL_DRIVER_NOPROMPT with equally hard-coded > SQL_DRIVER_COMPLETE. > + Simple. > + Probably more useful than current behaviour by default. > - In some situations the prompt can really need to be suppressed > (although I don't really know in which ones and we haven't run into > any of them while using libodbc++, which uses SQL_DRIVER_COMPLETE, for > several years before switching to SOCI).
Vadim, If you say it's more useful, I see no problem applying this approach straight away even if it's going to be improved in future. I mean, I have no problem leaving this decision to you. > 1. Allow having "PROMPT=0" or "PROMPT=1" in the ODBC connection string. > + Configurable. > - Not obviously discoverable and inconsistent with other SOCI backends > as we'd be using something that is not a valid connection string for > the underlying library. > - "PROMPT" could conflict with driver-defined attribute keywords allowed > by ODBC specification (standard ones are DSN, UID and PWD). My gut feeling says it's not best approach indeed :) > 2. Add static odbc_session_backend::enable_driver_prompt() method which > would affect the behaviour of the next session::open() calls. > + Configurable. > - Introduces a global variable. > - While not being really inconsistent with the other backends, it's very > ODBC-specific and wouldn't help if we need to provide any other such > "out of band" connection parameters in the other backends. One of dangers I see, it may initiate spread of more globals and each of them means a bit of new mess in public interface. > 3. Add some generic way to pass connection parameters other than those > specific by the connection string. E.g. add an optional > std::map<std::string, std::string> argument to session::open() which > would contain arbitrary key/value pairs that would be passed to the > backend. > + Generic. > - Untyped (i.e. too generic) and still difficult to discover. > - Most complex. I think this could be a basis for better solution. Generally, we need a mean to feed SOCI with (optional) configuration context carrying properties that can be consumed at every level of SOCI, core and backends: soci::session sql(backend, connection_string, configuration); It comes down to the decision of what we want to pass as the configuration. The std::map<std::string, std::string> is an obvious choice and with a bit of string-to-type converting internal machinery it would work well. Disadvantage: users will have to deal with type-to-string conversions on their own. Solution: we could add a bit more and provide soci::configuration class mapping std::string key to a T value. More advanced solution is to use Boost.PropertyTree as configuration carrier. Disadvantage: dependency on Boost headers (could be optional together with the configuration feature; compile-time configurable, though it would introduce #ifdef mess and maintenance hassle. Advantage: we have ready to use solution; we get added values like configuration file parsers and variety of formats supports (INI, JSON) If we are uncertain about the Boost dependency and we don't want to hard-wire Boost in public interface, we could go for the custom-tailored soci::configuration class that internally uses boost::property_tree and perhaps boost::variant. We can always replace it with different implementation, and the interface stays untouched. ATM, we see such need in ODBC, but new backends may have similar requirements, so if we solve it in generic way we would be ready for such requirements. Looking forward to discussing options? 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_jan _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
