[OT] Re: Binding rvalues to const ref in D

[Nick Sabalausky via Digitalmars-d]

On 10/20/2016 04:32 PM, Steven Schveighoffer wrote:
> On 10/20/16 12:50 PM, Nick Sabalausky wrote:
>>
>> You can't bind individual values? Is there something wrong with
>> "bindParameter(value, paramIndex)"? (I mean, besides the fact that it
>> takes a ref, and, like the rest of the lib, isn't really documented
>> anywhere outside of the code itself.)
[...examples involving out-of-scope data...]
> Now, there is bindParameters(Variant[]), which binds the *value* stored
> in each parameter to the fields. This was the only way I could do it
> without having to allocate space for individual values. But you must
> bind everything at once!

Ok, I see. Right.

Actually I hit the same problem myself yesterday adding a test for a PR 
that added support for setting null via Variant(null) instead of 
setNullParam. The bindParameters(Variant[]) was the only one I could use 
because you can't pass a null literal by ref.

>
> Honestly, the most egregious issue is the lifetime management. In some
> cases, if you pass or copy resource wrappers, the destructor will close
> the connection, or the above thing about having to allocate a place for
> values so you can bind parameters without worrying about their lifetimes
> going away. Wrapping mysql-native (which should be concerned mostly with
> low-level stuff) so I can make more suitable ranges out of the data was
> really hard, I ended up having to use RefCounted to make sure all the
> resource handles didn't go away!
>

Right, gotcha.

I hadn't really hit that much myself in the past because for a while I 
hadn't really been using the prepared statements much, nor using it 
without vibe's connection pool. But you're right, this stuff definitely 
needs fixed.

> I'll take a look when I can. One other thing API-wise that is horrendous
> is the handling of null parameters (especially when you have to insert
> multiple rows with the same prepared statement, and sometimes you have
> some fields that should be null). Nullable!T works awesome for vibe, I
> think mysql-native should use that model.
>

Yea, nulls were kind of always an awkward thing in the lib. I think the 
lib's original design might predate Nullable, which, I too am a fan of.

I think I'm going to try to put out first-try pass at a new API in a 
separate branch, try to get that out as soon as I can, and post it for 
experimentation/feedback.