[std.database]

[Regan Heath]

On Thu, 13 Oct 2011 05:42:04 +0100, Steve Teale  
<steve.teale at britseyeview.com> wrote:
> Also, while we're on the use-case track, can some of you please think
> about prepared statements, and what binding variables to them might look
> like?
>
> I'm working along the multiple lines of:
>
> setParam(T)(ref T t, enumDirection d);
> setParams(T...)(enumDirection d, T args);
> setParams(S)(S s, enumDirection d) if (is(S == struct));
> setParams(Variant[] va, enumDirection d);
>
> Do we have to assume that parameters that are IN, OUT, or INOUT will be
> required in some cases for stored procedure support?

I've used JDBC and some custom C++ code.  I think the JDBC approach is  
convenient/easy to understand and the C++ approach we used was very  
similar.  Both had the concept of specifying the parameter by index, so  
the code looked a bit like:

int index = 0;

setParam(index++, ..);
setParam(index++, ..);
setParam(index++, ..);
setParam(index++, ..);

It *might* be useful to retain the index idea to allow the setting of  
parameters in any order, but that might simply be flexibility that no-one  
really *needs* as I can't think of a reason why you would be forced to  
specify one before another.  The underlying API might require it however,  
but that wouldn't be a problem as internally we could just keep a  
parameter index and assign them in the order given.

As for IN, OUT, INOUT.  I've never had cause to use INOUT.  I bind input  
using SQLBindParameter (specifying INPUT and not INPUT_OUTPUT or OUTPUT)  
and obtain results using SQLBindCol (as a select effectively),  
occasionally binding a column for a COUNT or similar 'result'.  I believe  
the use case for INOUT will be store procedures as you've mentioned, all  
mine are handled by IN params and colum/select output (a single result in  
my case).  I think we're going to need to handle all 3 types for maximum  
flexibility.

> There's also the question of dealing with large column data. JDBC, I
> think, uses streams to interface to such things, but I wonder if
> providing delegates as part of the binding process might be better. Any
> thoughts?

I've never used streams, but then I've never used large columns where it  
might be appropriate - or I've had the memory/a reason to load the  
complete column up front.  But, if I was going to I would probably use a  
stream, it makes sense to me.

What about ranges, could they be used?

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/