On 10 February 2013 23:37, Vadim Zeitlin <[email protected]> wrote:
> 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.
I agree.
> 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()?
That sounds like we could open the path to further interface bloat.
> Or do you think I'm overthinking this and adding connect_options to the
> existing methods won't do any harm?
I don't think you're overthinking.
But, perhaps there is a better way than growing list of parameters too.
> 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.
That sounds closer to what I've been thinking of.
> What do you think, do you have any preferences here or maybe some other,
> better ideas?
Yet another proposal open for comments:
What about using the little Encapsulated Context pattern?
Here is an overview with some examples listed in "Known Uses"
http://accu.org/index.php/journals/246
Here is another good example, also closely related to what we've
already discussed, in
"Pattern Story: A Tale of Alternative Implementations in C++"
http://www.two-sdg.demon.co.uk/curbralan/papers/europlop/ContextEncapsulation.pdf
I think such environment/context object for session could gather all
necessary details:
- what backend_factory is used
- connection string
- connection control settings
- ...
Implementation options:
1) Keep current soci::session interface for backward compatibility,
add new ctor and open() taking the context - less intrusive, good for SOCI 3.2.0
2) Replace current ctor/open() with single new ones taking only the
context object,
this could be practical for SOCI 4.0.0 which may no longer be
compatible with SOCI 3.x.
The context/environment could have implicit ctor taking
(backend_factory, connection_string)
so old way of calling is also available.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
------------------------------------------------------------------------------
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
