On Sat, 2 Feb 2013 21:37:58 +0000 Mateusz Loskot <[email protected]> wrote:
ML> On 31 January 2013 21:11, Vadim Zeitlin <[email protected]> wrote: ML> > At least under Windows, it's common for the ODBC driver to show a dialog ML> > box to the user asking to enter the missing information when connecting via ML> > a predefined DSN. Typically, the password is not stored in the DSN, where ML> > it could be easily seen, but entered during connection time in this dialog ML> > box. ML> > ML> > [...] ML> > So I see several alternatives, let me list them here ML> > with their pros and cons: ML> > ML> > 0. Just replace the hard-coded SQL_DRIVER_NOPROMPT with equally hard-coded ML> > SQL_DRIVER_COMPLETE. ... ML> If you say it's more useful, I see no problem applying this approach ML> straight away even if it's going to be improved in future. Well, in my situation it's definitely more useful because we're basically working with user-defined DSNs which may or may not include login/password information. I am not completely sure if there are no other situations in which this behaviour is inappropriate though -- as I wrote, I can't think of any, but it could be just due to my lack of experience with ODBC. ML> I mean, I have no problem leaving this decision to you. I think I might have a problem with this though :-/ ML> > 1. Allow having "PROMPT=0" or "PROMPT=1" in the ODBC connection string. ML> > + Configurable. ML> > - Not obviously discoverable and inconsistent with other SOCI backends ML> > as we'd be using something that is not a valid connection string for ML> > the underlying library. ML> > - "PROMPT" could conflict with driver-defined attribute keywords allowed ML> > by ODBC specification (standard ones are DSN, UID and PWD). ML> ML> My gut feeling says it's not best approach indeed :) FWIW we could use something like "SOCI_OPTION_PROMPT" to reduce (and, in practice, eliminate) the risk of such conflict. It would still remain ugly though. ML> > 3. Add some generic way to pass connection parameters other than those ML> > specific by the connection string. E.g. add an optional ML> > std::map<std::string, std::string> argument to session::open() which ML> > would contain arbitrary key/value pairs that would be passed to the ML> > backend. ML> > + Generic. ML> > - Untyped (i.e. too generic) and still difficult to discover. ML> > - Most complex. ML> ML> I think this could be a basis for better solution. OK, let me try to do this then. ML> It comes down to the decision of what we want to pass as the configuration. ML> The std::map<std::string, std::string> is an obvious choice and with ML> a bit of string-to-type converting internal machinery it would work well. ML> ML> Disadvantage: users will have to deal with type-to-string conversions ML> on their own. Yes, there is that, although to me the lack of type safety is more important. String conversions are annoying (in C++), but this is not something that would be used very often, would probably be used half of the time for parameters which are strings anyhow, so basically I just don't think it's going to create big problems in practice. ML> Solution: we could add a bit more and provide soci::configuration ML> class mapping std::string key to a T value. The trouble is that not all options would use the values of the same type, so we'd need either a heterogeneous container or use Boost.Any for T and this IMHO would start getting too complicated for something basically as simple as this. ML> More advanced solution is to use Boost.PropertyTree as configuration ML> carrier. I must say I disagree relatively strongly with this for several reasons: 0. Extra dependency. I'd like to keep the possibility to use SOCI on platforms where this might matter. 1. Basic data model mismatch: we don't need a tree as there is no hierarchal structure in play here. 2. Smells like over-engineering: we don't need to read/write these objects to file and we definitely don't need XML nor JSON (nor even INI) here. ML> Looking forward to discussing options? I'd like to propose with the solution based on adding a soci::backend_options class which would just wrap std::map<string, string> but might provide a simpler/higher level adapter over it. Then we could use the simplest possible implementation for now and something more powerful later if really needed. One question which is immediately going to appear: should the backends complain about the unknown options or silently ignore them for forward (and perhaps cross-backend) compatibility? What do you think? Thanks, VZ
pgphLgR2mPID8.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
