Consider having mysql-native join dlang-community

[EmTee70]

I just want to encourage you to try to put mysql-native under the umbrella of https://github.com/dlang-community there are to many mysql libs in dub (code.dlang.org) in the moment and it looks that your implementation is the best. By this step, I am sure your project might gain more visibility and could be a prototype for other DB drivers developed and pushed by the community. When I started with D I needed a mysql driver, I took the one with the highest version number, not your project in that moment, now it looks more obvious to give myslq-native the first try, especially because of your docs.
Best regards mt.

[Abscissa]

It's certainly not a bad idea, but I'm currently on the fence about this. Dlang-community is certainly a fantastic project, but I'm uncertain how much a project like mysql-native really has to benefit from it beyond a little bit of marketing. Most of what it offers, mysql-native can probably handle on its own. And (just going by my gut impression) I'm not sure dlang-community is really intended to be a one-stop-shop for recommended D projects. My impression is that it specializes in projects that are in need of extra support. So I'm not sure whether mysql-native is, or isn't, the sort of thing dlang-community is really looking for, or not.

But I'm certainly not opposed to the idea.

I'd like to hear more from the dlang-community folks on their opinions about how well mysqln would fit their vision. And what they have in mind for the mid-to-long-term vision for dlang-community, and what commitments/responsibilities/conformity that would entail from mysql-native.

I'm not ready to jump head-first into it right at the moment, but I'm certainly open to the idea, especially if both projects' visions are suitably in line with each other.

[EmTee70]

Thank you for your fast answer! I will ask Sebastian Wilzbach, as one of the more active members, about "their projects' visions", so I get a better understanding about it. Keep your updates coming!

[schveiguy]

I think this probably isn't going to happen, and I'm not sure it's the correct path, but still can be considered. Any updated thoughts @EmTee70 ?

[EmTee70]

Sorry, for late response, my speed tests for mysql-native in conjunction with vibe.d was a little negative. Now I switched away from mysql-d, which is not maintained and produces a lot of deprecation warnings but still working, to the original implementation from in Adam's ards package. I am not sure, why the use of mysql-native inside my app slows it down so much, may be, there are more conversions happening (MYSQL delivering a String representation -> "Values" (like int and float) in mysql-native -> String in Vibe.d output ???

I have the (for me) old idea - to try to write an embedded (normally in C) mysql function rendering a diet-template on output inside the mysqlserver, so the sql server would function directly as a micro ervice delivering HTML. To include in a ruby on rails app....

But back to the question: In general there is a big problem finding reliable third party libs in DUB site (code.dlang.org), so I would love to have some kind of additional maker - to tag packages being recommended to use by the D Foundation ensuring they are not dropped, when the original owner stops to support it.

[schveiguy]

After the next update to an all-@safe possibility of mysql-native, I plan on focusing on performance. I think there's quite a bit of power we are leaving on the table in the way things are built. I'm hoping to create a low-level layer that focuses only on the protocol, and then allows building whatever system you want on top of it.

But we are talking a long time in the future. Meanwhile, I'm OK with mysql-native living in its own org for now.