mysql-native v2.1.0

[Nick Sabalausky (Abscissa)]

On 03/06/2018 01:54 PM, bauss wrote:
> On Tuesday, 6 March 2018 at 18:36:45 UTC, bauss wrote:
>>
>> Like more specifically do I still call lockConnection() on a MySQLPool?

If you're using vibe.d and MySQLPool, then yes. But that's completely 
unrelated to prepared statements, it has nothing to do with whether or 
not you're using them, or how you're using them.


> I think it would be easier to help me if I put some examples.
> 
> I just tried changing stuff and I can't seem to get it working.
> 
> I kept using lockConnection() as before, I assume it's the right way.
> 
> Then I changed the way I retrieve prepared statements from:
> 
>    auto prepared = prepare(connection, sql);
>    prepared.setArgs(params);
> 
> to:
> 
>    auto prepared = connection.prepare(sql);
>    prepared.setArgs(params);
> 

Either way works. That's just a matter of whether you're using D's 
"UFCS" (uniform function-call syntax) feature or not.

> Then ex. for reading many entries:
> 
> From:
> 
>    return prepared.querySet().map!((row)
>    {
>      auto model = new TModel;
>      model.row = row;
>      model.readModel();
>      return model;
>    });
> 
> To:
> 
>    return connection.query(prepared).map!((row)
>    {
>      auto model = new TModel;
>      model.row = row;
>      model.readModel();
>      return model;
>    });
> 
> But it doesn't seem to work.
> 
> I get the following exception:
> 
> "Attempting to popFront an empty map" which I assume is because the 
> result is empty.
> 

Ok, now that one is a little weird. Should work as far as I can tell. 
I'd say file a ticket here with a minimized test case I can just run on 
my machine to reproduce the error. Please make sure the test case shows 
the return type of the function in question (and whether or not it's 
simply "auto") and how its used that leads to the error:

https://github.com/mysql-d/mysql-native/issues

Also, be aware that the updated equivalent to `querySet` is 
`query(...).array()`, not plain `query(...)`. However, based on the 
portion of code you've posted, I don't see why it shouldn't work as-is. 
I'd have to examine a complete test-case to get to the bottom of that.

My best guess is that the code which is CALLING your functions above may 
be doing something wrong with the range being returned. But again, 
without a complete test-case, the best I can do is make guesses.