On 3 February 2013 21:39, Vadim Zeitlin <[email protected]> wrote: > 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> > > 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.
I assume it would not affect use of FILEDSN, then my opinion is simply go for it and apply the changes you need :) > 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. Yup, ugly :) > 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++), Yes, especially in in pre C++11. Later, with C99 and std::to_string life becomes easier. > 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. Sure. > 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. Generally, I agree, but I wouldn't call this problem simple. The idea is simple, to have a map with settings, but realisation of such things is usually elaborate. We already some bits of this kind used to perform type erasure in SOCI, see holder and type_holder classes use by row class. > 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. Agreed. > 1. Basic data model mismatch: we don't need a tree as there is no > hierarchal structure in play here. Agreed. I was being lazy :) > 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. Not agreed. I'd like to be able to pass .ini or .json (simple SOCI-custom format) file to std::session::open() as more convenient than juggling strings. would be useful for testing. But, such ability is not critical for your problem, of course. > 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. Sure, but in case string juggling and conversions become nightmarish, IMHO, feel free to consider using type_holder/holder idea from the row or simply including this tiny implementation of any class: http://www.eld.leidenuniv.nl/~moene/Home/tips/any/ http://www.eld.leidenuniv.nl/~moene/Home/tips/any/code/ > 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? I'd vote for ignoring. This could also leave us a chance to use this mechanism to pass some options used at the level of core (As I mentioned in my previous post, if there are/will be some configurable features in the core, such settings objects could be used to pass related options; such options would not be used by backends, so ignored.) 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
