On Thursday, 8 March 2018 at 06:49:52 UTC, Nick Sabalausky
(Abscissa) wrote:
On 03/07/2018 02:32 PM, bauss wrote:
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.
query() returns an input range. You can only access one element
at a time (as its read from the network) and you don't know how
many there are ahead of time, BUT it avoids allocating a whole
array to store everything.
In addition to query(), there used to also be a querySet(). The
querySet() would allocate an array and read ALL the results
into it so you could get random-access. But that's exactly what
you already get when you call array() on an input range (such
as the input range returned by query), so querySet was deemed
redundant and eliminated.
So if you had code that *did* need an array allocated to store
all the results, then "querySet()" has been replaced with
"query().array". But like you said, if you don't really need
the array, then there's no need to call array() and waste the
memory.
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.
Using mysql-native with vibe.d isn't any different from using
it without vibe.d.
It's recommended to use MySQLPool to make a Connection rather
than doing "new Connection" directly simply because connecting
is faster that way (though "new Connection" will still work).
But aside from that, there is absolutely nothing different
about mysql-native whether you're using vibe.d or not.
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?
Does your application need to support multiple connection
strings while it's running? That's pretty rare unless you're
making something like phpMyAdmin (and even then, I'd probably
do it a little differently). Normally you'd just make one
connection pool:
MySQLPool pool;
Then "new" that once with your connection string when you start
up, and you're good.
I guess I can imagine some potential use-cases that get more
complicated than that, but that's really up to your own
project's needs.
> 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.
I'm only guessing here, but I wonder if that might be because
you seem to be trying to share pools and connections across
threads. I don't know whether vibe is designed to share TCP
connections across threads or not. I'd say, try ripping out all
that shared/__gshared/synchronized stuff and see how that works.
But if you can't store the pools anywhere, how are you supposed
to use them with vibe.d?
Creating a new pool for every thread seems expensive and dosn't
that defeat the purpose of using pools in the first place?
I mean a 1000 people could connect to a website and potentially
that could create a thousand threads (It probably won't, BUT it
could.) and thus it can't be afforded to create a pool per
request.
I mean it's kind of a corner case, but it's a common corner case
for big applications.
I don't create any explicit threads.
But like I said, it seems to work after I stopped returning the
connection and just the pool.
so I think the problem wasn't the pool, but the connection itself.
At least I can't reproduce it and tried with hundreds of queries
at once and before I could reproduce with less than 10.
And yes I need support for multiple connection strings. It's not
an application, it's a library for writing enterprise
websites/webapis and thus it should be scalable, since most
enterprise solutions uses multiple databases.
