On Mon, 4 Feb 2013 01:05:39 +0000 Mateusz Loskot <[email protected]> wrote:
ML> On 3 February 2013 21:39, Vadim Zeitlin <[email protected]> wrote: ... ML> > I'd like to propose with the solution based on adding a ML> > soci::backend_options class which would just wrap std::map<string, string> ML> > but might provide a simpler/higher level adapter over it. Then we could use ML> > the simplest possible implementation for now and something more powerful ML> > later if really needed. Hello again, I've started implementing this today but the more I was looking at it, the less sure I was becoming about the idea of adding an extra argument to all the existing session opening functions. I.e. consider that currently we have class SOCI_DECL session { public: session(); session(backend_factory const & factory, std::string const & connectString); session(std::string const & backendName, std::string const & connectString); explicit session(std::string const & connectString); void open(backend_factory const & factory, std::string const & connectString); void open(std::string const & backendName, std::string const & connectString); void open(std::string const & connectString); ... }; And now we'd need to tack on an extra "connect_options const & options = connect_options()" to the end of each of these methods. They are not very readable already, and adding another argument really won't help. So perhaps I should avoid touching the ctors and add another family of overloads with "connect_options" at the end, called, say, open_with_options()? Or do you think I'm overthinking this and adding connect_options to the existing methods won't do any harm? BTW, there is also a rather wild idea of replacing the existing "connectString" argument with some "connectionDescription" one combining both the string and the options. For backwards compatibility we'd have an implicit connect_desc ctor from std::string but we could also add methods such set_option("name", "value") on this object. This seems a bit too smart for its own good but OTOH this kind of makes sense and would allow us to avoid having to introduce open_with_options() while also avoiding increasing the number of arguments to the existing overloaded functions. What do you think, do you have any preferences here or maybe some other, better ideas? TIA, VZ
pgpI7Tf7JAJmG.pgp
Description: PGP signature
------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
