mysql-native v2.1.0

[bauss]

On Wednesday, 7 March 2018 at 10:14:08 UTC, Nick Sabalausky 
(Abscissa) wrote:
> 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.

Wait why has it been updated to array() ? So it's not a real 
range anymore? Or was it always represented as an array behind 
the scenes?

I just feel like allocating it into an additional array is a 
waste of memory? But if it was always like that I guess it 
doesn't matter.

However idk what I changed, but the issue stopped for me.

However I still have this issue:

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

(Currently trying to see if I can make a minimal example, but 
it's kinda hard to make a minimal example since it's from my 
Diamond MVC (vibe.d) library and it isn't used until deep nesting 
of the application.

Anyway before I report anything else I could easily be doing 
something wrong. There hasn't exactly been any good examples on 
how to use it with vibe.d so it has pretty much been a trial and 
error thing for me.

So basically I keep an associative array of connection pools 
based on connection strings like below:

private static __gshared MySQLPool[string] _pools;

And then I retrieve a connection with the function below.

Perhaps I'm not supposed to make a new pool every time, but there 
is someway to retrieve a pool already? Maybe that's what I'm 
doing wrong?

private static shared globalPoolLock = new Object;

private Connection getMySqlConnection(string connectionString)
{
   auto pool = _pools.get(connectionString, null);

   if (!pool)
   {
     synchronized (globalPoolLock)
     {
       pool = new MySQLPool(connectionString);

       _pools[connectionString] = pool;
     }
   }

   return pool.lockConnection();
}

After I retrieve the connection then it's basically like the code 
I showed you, but that seem to be correct, yes?