[boost] SOCI db lib [Was: RTL status -"help wanted"]

From: Steve Hutton (shutton_at_[hidden])
Date: 2004-10-19 22:21:18

In article <4174BEAB.6070805_at_[hidden]>, 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