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.
Yes.
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.
I understand Beman's comment to mean that the committee prefers libraries that are the thinnest layer above the underlying technology that provides sufficient abstraction.
Yes.
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 factory).
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. --Beman