Re: [boost] Re: RTL status -"help wanted". Was: Library Proposal: database (boost::db)

From: Maciej Sobczak (prog_at_[hidden])
Date: 2004-10-19 02:13:47

Steve Hutton wrote:

>>I have just moved the SOCI project to SourceForge, to gain some 
>>attention of develpers who may have expertise in interfacing with 
>>database engines other than Oracle:
>>
>>http://soci.sourceforge.net/
>>
>>The idea was to enable users with simple needs to write simple code. 
>>Yes, complete and sophisticated DB library is a huge effort, but 
>>straightforward solutions seem to fit the bill in most of the cases.
> 
> 
> 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.

> Have you considered these features and how they might be exposed
> through soci?

To be frank, no.
The library was meant to be a simple tool for simple needs and as a 
sword against anybody who got into belief that (db) programming in the 
language beginning with 'J' is easier. ;)

OK, I'm serious again.

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.
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);

What do you mean by "explicit support"?

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.

Looking with increasing interest how this topic may continue,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/