An all-D MySQL/MariaDB client library:
https://github.com/mysql-d/mysql-native
==========================================

Tagged 'v2.1.0', which mainly adds a few new features, including greatly simplified shortcut syntax for prepared statements (with automatic, implicit caching and re-use):

---
int i = 5;
string s = "Hello world";
conn.exec("INSERT INTO table_name VALUES (?, ?)", i, s);
conn.query("SELECT * FROM table_name WHERE id=? AND name=?", i, s);

// Also works:
Prepared stmt = conn.prepare("INSERT ...blah... (?, ?)");
conn.exec(stmt, i, s);
---

As well as additional tools for optional micro-management of registering/releasing prepared statements.

It also fixes #28: "MYXProtocol thrown when using large integers as prepared parameters."

Full changelog
https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md#v210---2018-03-02

On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote:
> An all-D MySQL/MariaDB client library:
> https://github.com/mysql-d/mysql-native
> ==========================================
>
> [...]

Is unix socket connection supported? I'm not seeing any information about it in the docs.

On 03/05/2018 09:23 AM, aberba wrote:
> On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote:
>> An all-D MySQL/MariaDB client library:
>> https://github.com/mysql-d/mysql-native
>> ==========================================
>>
>> [...]
> 
> Is unix socket connection supported? I'm not seeing any information about it in the docs.

It's not currently supported. From the "Additional Notes" section of the readme:

"Normally, MySQL clients connect to a server on the same machine via a Unix socket on *nix systems, and through a named pipe on Windows. Neither of these conventions is currently supported. TCP is used for all connections."
  - https://github.com/mysql-d/mysql-native#additional-notes

I'm not opposed to it being added, but I'm not aware of what benefit it would provide that would big enough to make it a priority. Also, AFAIK, vibe doesn't offer socket support like it does TCP, so vibe users would loose out on the automatic yield-on-io that's a cornerstone of vibe's concurrency design.

On Tuesday, 6 March 2018 at 04:31:42 UTC, Nick Sabalausky (Abscissa) wrote:
> On 03/05/2018 09:23 AM, aberba wrote:
>> On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote:
>>> An all-D MySQL/MariaDB client library:
>>> https://github.com/mysql-d/mysql-native
>>> ==========================================
>>>
>>> [...]
>> 
>> Is unix socket connection supported? I'm not seeing any information about it in the docs.
>
> It's not currently supported. From the "Additional Notes" section of the readme:
>
> "Normally, MySQL clients connect to a server on the same machine via a Unix socket on *nix systems, and through a named pipe on Windows. Neither of these conventions is currently supported. TCP is used for all connections."
>   - https://github.com/mysql-d/mysql-native#additional-notes
>
> I'm not opposed to it being added, but I'm not aware of what benefit it would provide that would big enough to make it a priority. Also, AFAIK, vibe doesn't offer socket support like it does TCP, so vibe users would loose out on the automatic yield-on-io that's a cornerstone of vibe's concurrency design.


UNIX sockets provide a way to securely connect in an enclosed/isolated environment without exposing connection externally. This is used in my company in our microservice infrastructure on Google Cloud: we connect to our db instance using a proxy and its the recommended approach in microservices.

Its a very common security practice. The default approach on Google Cloud. I would do the same for any db I want to prevent external access to. If vibe.d doesn't support it then its missing a big piece of a puzzle.

On Tuesday, 6 March 2018 at 07:39:00 UTC, aberba wrote:
> On Tuesday, 6 March 2018 at 04:31:42 UTC, Nick Sabalausky (Abscissa) wrote:
[...]
>> I'm not opposed to it being added, but I'm not aware of what benefit it would provide that would big enough to make it a priority. Also, AFAIK, vibe doesn't offer socket support like it does TCP, so vibe users would loose out on the automatic yield-on-io that's a cornerstone of vibe's concurrency design.
>
>
> UNIX sockets provide a way to securely connect in an enclosed/isolated environment without exposing connection externally. This is used in my company in our microservice infrastructure on Google Cloud: we connect to our db instance using a proxy and its the recommended approach in microservices.
>
> Its a very common security practice. The default approach on Google Cloud. I would do the same for any db I want to prevent external access to. If vibe.d doesn't support it then its missing a big piece of a puzzle.
Having sockets would be better, but you may configure your mysql to allow only
local connects. So external requests are blocked.

https://dba.stackexchange.com/questions/72142/how-do-i-allow-remote-mysql-access-to-all-users

Look at the first answer to set the right privileges for your environment.

Additionally blocking the mysql port 3306 (beside many others) from outside the network would make sense.

On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote:
> An all-D MySQL/MariaDB client library:
> https://github.com/mysql-d/mysql-native
> ==========================================
>
> Tagged 'v2.1.0', which mainly adds a few new features, including greatly simplified shortcut syntax for prepared statements (with automatic, implicit caching and re-use):
>
> ---
> int i = 5;
> string s = "Hello world";
> conn.exec("INSERT INTO table_name VALUES (?, ?)", i, s);
> conn.query("SELECT * FROM table_name WHERE id=? AND name=?", i, s);
>
> // Also works:
> Prepared stmt = conn.prepare("INSERT ...blah... (?, ?)");
> conn.exec(stmt, i, s);
> ---
>
> As well as additional tools for optional micro-management of registering/releasing prepared statements.
>
> It also fixes #28: "MYXProtocol thrown when using large integers as prepared parameters."
>
> Full changelog
> https://github.com/mysql-d/mysql-native/blob/master/CHANGELOG.md#v210---2018-03-02

I'm unsure how I'd go about implementing prepared statements in a vibe.d application correctly.

With older versions it didn't work properly and I'm not sure how to implement it with the new version of prepared statements.

I can't seem to find any examples on how they were updated and what exactly to change in my code.

It would be nice with some more examples that aren't basics.

Especially, because I call setArgs() to set arguments from an array since I have no control over the arguments passed to the function as they're generated elsewhere and thus I cannot manually specify the arguments.


I guess I will try to dig around and see what works and what doesn't, unless you can pinpoint me in the correct direction.

On Tuesday, 6 March 2018 at 18:31:08 UTC, bauss wrote:
> On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote:
>> [...]
>
> I'm unsure how I'd go about implementing prepared statements in a vibe.d application correctly.
>
> [...]

Like more specifically do I still call lockConnection() on a MySQLPool?

On Tuesday, 6 March 2018 at 18:36:45 UTC, bauss wrote:
> On Tuesday, 6 March 2018 at 18:31:08 UTC, bauss wrote:
>> On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote:
>>> [...]
>>
>> I'm unsure how I'd go about implementing prepared statements in a vibe.d application correctly.
>>
>> [...]
>
> Like more specifically do I still call lockConnection() on a MySQLPool?

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);

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.

So what am I doing wrong in using prepared statements with the new updates?

On Tuesday, 6 March 2018 at 10:15:30 UTC, Martin Tschierschke wrote:
> On Tuesday, 6 March 2018 at 07:39:00 UTC, aberba wrote:
>> On Tuesday, 6 March 2018 at 04:31:42 UTC, Nick Sabalausky (Abscissa) wrote:
> [...]
>>> [...]
>>
>>
>> UNIX sockets provide a way to securely connect in an enclosed/isolated environment without exposing connection externally. This is used in my company in our microservice infrastructure on Google Cloud: we connect to our db instance using a proxy and its the recommended approach in microservices.
>>
>> Its a very common security practice. The default approach on Google Cloud. I would do the same for any db I want to prevent external access to. If vibe.d doesn't support it then its missing a big piece of a puzzle.
> Having sockets would be better, but you may configure your mysql to allow only
> local connects. So external requests are blocked.
>
> https://dba.stackexchange.com/questions/72142/how-do-i-allow-remote-mysql-access-to-all-users
>
> Look at the first answer to set the right privileges for your environment.
>
> Additionally blocking the mysql port 3306 (beside many others) from outside the network would make sense.

The MySQL instance is running in a managed cloud instance. You don't get to tweak things like with vps.  Proxy based connection its what's used. Not just in my case...it supported in all major mysql libraries "socketPath".

On Wednesday, 7 March 2018 at 09:16:42 UTC, aberba wrote:
> On Tuesday, 6 March 2018 at 10:15:30 UTC, Martin Tschierschke wrote:
[...]
>>> [...]
[...]
>
> The MySQL instance is running in a managed cloud instance. You don't get to tweak things like with vps.  Proxy based connection its what's used. Not just in my case...it supported in all major mysql libraries "socketPath".
OK, so, no useful hint from me....