From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-12-06 14:33:59
Nicola Musatti wrote:
> ... You just need to provide access to your backends from textual
> keywords, possibly making it possible for vendors to default to their
> preferred one when none is specified.
Yes, that is what I had in mind. If the textual name isn't supplied by
the vendor, it is simply a error. Users can fallback to the vendor
default, or obtain the missing backend from a third-party.
> SOCI may come to satisfy two very different needs: provide a well tested
> end user interface for standardization *and* a practical, open source
> solution for accessing your databases. The standard interface may not
> mention specific backends, but commercial solutions will have to compete
> with what SOCI offers free of charge. In a way, even if vendors were to
> rip SOCI's implementation and call it their product it would be a success.
> I don't think how backends are provided is really a concern from the
> committee's point of view, even if it is of high practical importance.
Yes. I'm of the personal opinion that the committee should require that
a default backend be provided, but which one isn't likely to specified
in the standard.
> understand Beman's comment to mean that the committee prefers libraries
> that are the thinnest layer above the underlying technology that
> provides sufficient abstraction.
> In other words SOCI should not attempt
> to provide a complete object/relational mapping with all bells and whistles.
The committee might also like higher level functionality, perhaps even
"a complete object/relational mapping with all bells and whistles," but
that higher level functionality should be built on top of the lower
level functionality. How this plays on for SOCI, I don't know yet.
>>> Speaking of third-parties, requiring the user to include headers
>>> specific to particular back-ends sounds controversial, although I
>>> haven't studied SOCO's interface yet so don't know that for sure.
>> You don't include third-party API. You only include the header that
>> gives you visibility of the given factory.
>> In other words, in order to do this:
>> Session sql(oracle, "some params");
>> you need to #include "soci.h" (for Session and other independent stuff)
>> and "soci-oracle.h" (so that you see oracle as the name of the singleton
> As I said I think that even this can and should be done away with.
I'm also concerned, although I want to understand more before absolutely
saying that the approach should be changed.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk