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.
