In article <4174BEAB.6070805@msobczak.com>, Maciej Sobczak wrote:
Steve Hutton wrote:
Actually I think you have done a good chunk of the work already. SOCI looks to be just a few features away from being complete:
o explicit support for stored procedures
o bulk updates
o result set meta-data
You can also add array binds. One user asked for it. I'm not sure, though, whether this feature is Oracle-specific and can be applied with other DB interfaces.
What do you mean by array binds? Bind which way ("into" or "use")?
The SOCI library is highly syntax-oriented and is meant to provide the functionality that I've seen in some RAD tools (SQL embedding). I avoided adding any functionality that would be inconsistent with the rest of the interface or that I just never used. For those who may need more advanced stuff, the OCI handles are publicly available, so it is possible to mix SOCI code with low-level OCI calls.
I understand, it's just that if these 3 features were there I think it would move coverage from say 85% of use cases to 99%. I was wondering if these features could be possibly added through additional explicit classes, similar to how explicit use of the Statement class provides prepared statement functionality, but can be ignored when not needed.
Also, it should be possible to call stored procedures using just what is already provided. Something like:
sql << "BEGIN myproc(:param1, :param2); END;", use(var1), use(var2);
Right, that is no problem for an Oracle only library. Unfortunately this is one of the errors where vendors do not use a consistant syntax. By explicit stored procedure support I meant a Procedure object that would take care of the required syntax automatically - users would just pass the name of the procedure.
If there is any interest in pushing this library forward, I would really need some help with judicious interface design, especially in the areas where I have not enough expertise as a user.
Also, the library was initially writen with the idea to be free of any dependencies. Now, as we're talking *here*, it is sensible to point out that the library may benefit from some "boostifying". For example, the Boost optional may be used to cover NULL values, shared_ptr may be used to manage the lifetime of expression objects, etc.
And last but not least - I have no expertise in ODBC (other than MFC wrappers, yuck...) and it looks to be highly requested. My choice of Oracle and OCI was obvious in the environments where I hang around for most of the time, but it seems to be not so obvious to more general audience. This is another area where some help would be needed.
I suspect ODBC is a popular choice for implementers because it brings support for multiple databases. There is certainly precedent for porting OCI code to ODBC - that's the path taken by OTL. Steve