On 04/08/2014 09:52 AM, Nick Sabalausky wrote:
> On 4/8/2014 2:51 AM, simendsjo wrote:
>>
>> This is great news. If you look at the simendsjo repo, there's a rewrite
>> in progress, but it's still missing some key features.
>> The rejectedsoftware repo is the one in production use.
>>
>> Here's a TODO:
>> http://forum.dlang.org/post/zsfxoggzwkmqjzyxbwgc@forum.dlang.org
>>
>
> It looks like at least some of that TODO takes things beyond where the
> rejectedsoftware version is, which is good, of course. But what would
> you say are the things needed just to bring it up to parity with the
> rejectedsoftware version? (So we could declare it the new "official" and
> either replace or deprecate the current one.)

What comes to mind is
* Stored Procedures
* Purging results (cancelling queries)
* Sending and receiving large blobs

But if this should become the official version, more thought should go into the API, or we should build a "fully" compatible API.

By "fully", I mean as much as possible - there are some very odd behavior regarding passing values to stored procedures in the original code that shouldn't be replicated.

On 4/8/2014 2:51 AM, simendsjo wrote:
>
> This is great news. If you look at the simendsjo repo, there's a rewrite
> in progress, but it's still missing some key features.
> The rejectedsoftware repo is the one in production use.
>
> Here's a TODO:
> http://forum.dlang.org/post/zsfxoggzwkmqjzyxbwgc@forum.dlang.org
>

FWIW, I've just tried running the tests.

In short, it seems to work fine on Windows 32-bit, although my MySQL server breaks a few minor unittests.

Details:

- Server: MySQL version "5.0.91-community-nt" (probably getting old but, meh, it's just for local testing) running on a Win7 64-bit box. I'm not sure if the MySQL server itself is a 32-bit or 64-bit version (don't recall, and the admin panel isn't telling me).

- Client 1: The same Win7 box, using DMD to compile a 32-bit exe.

- Client 2: Linux Mint 15, 32-bit VM (DMD again).

Everything behaved exactly the same between the two clients. Everything passed except for a few asserts in the "information_schema" section. There were two things that went wrong:

- For me, field.table was always empty string, on all 4 entries in the field list (instead of "information_schema" as expected).

- For me, the first two entries in the field list had lengths of 192, instead of 96 as expected.

On 4/8/2014 5:40 AM, Nick Sabalausky wrote:
>
> - For me, field.table was always empty string, on all 4 entries in the
> field list (instead of "information_schema" as expected).
>

Sorry, I meant to say "...field.***schema*** was always empty string..."

On Tuesday, 8 April 2014 at 07:58:58 UTC, simendsjo wrote:
> On 04/08/2014 09:52 AM, Nick Sabalausky wrote:
>> On 4/8/2014 2:51 AM, simendsjo wrote:

>
> What comes to mind is
> * Stored Procedures
> * Purging results (cancelling queries)
> * Sending and receiving large blobs
>

The original did all of these, and user-defined functions. At the time MySQL did not support strored procedures that returned a result set. Maybe it does not but I have not investigated that yet.

Steve

On 04/08/2014 04:00 PM, Steve Teale wrote:
> On Tuesday, 8 April 2014 at 07:58:58 UTC, simendsjo wrote:
>> On 04/08/2014 09:52 AM, Nick Sabalausky wrote:
>>> On 4/8/2014 2:51 AM, simendsjo wrote:
>
>>
>> What comes to mind is
>> * Stored Procedures
>> * Purging results (cancelling queries)
>> * Sending and receiving large blobs
>>
>
> The original did all of these, and user-defined functions. At the time
> MySQL did not support strored procedures that returned a result set.
> Maybe it does not but I have not investigated that yet.
>
> Steve

I think most of what's needed for stored procedures is implemented.

On Tuesday, 8 April 2014 at 14:10:19 UTC, simendsjo wrote:

> I think most of what's needed for stored procedures is implemented.

OK, can you give me a brief run-down on the changes you would like to see/are working on. Then we can get together and agree on an outcome that makes the best of both our points of view.

I am not inflexible. When I dropped out it was because there was just no consensus. Now, I don't give a **ck if there's consensus or not. The main thing is 1) does it work, ans 2) does it provide what D programmers might expect in the context of the language features and Phobos custom and practice.

Those who want something completely different are most welcome to use our stuff and do it themselves.

Deal?

Steve

On Tuesday, 8 April 2014 at 14:10:19 UTC, simendsjo wrote:
> On 04/08/2014 04:00 PM, Steve Teale wrote:
>> On Tuesday, 8 April 2014 at 07:58:58 UTC, simendsjo wrote:

On a more specific topic, Nick S mentioned purging of result sets.

I have a mixed view of this. One half of me says "if you cant present a SQL query that selects what you want, then put up with the inefficiency of waiting for the thread to read through all the stuff until it finds an EOF".

The other half wonders if there should be a connection pool, and then situations like that could just switch to a new connection, and leave the existing one at lower priority to clean up the garbage.

But the latter is not systems programming approach.

Writing that down cleared my mind. The level we should aim at should I think be just what is needed to exploit the capabilities of the MySQL/MariaDB protocol version. The protocol is what it is, and is unfriendly toward sloppy SQL.

Steve

On 4/8/2014 11:49 AM, Steve Teale wrote:
> On Tuesday, 8 April 2014 at 14:10:19 UTC, simendsjo wrote:
>
>> I think most of what's needed for stored procedures is implemented.
>
> OK, can you give me a brief run-down on the changes you would like to
> see/are working on. Then we can get together and agree on an outcome
> that makes the best of both our points of view.
>
> I am not inflexible. When I dropped out it was because there was just no
> consensus. Now, I don't give a **ck if there's consensus or not. The
> main thing is 1) does it work, ans 2) does it provide what D programmers
> might expect in the context of the language features and Phobos custom
> and practice.
>
> Those who want something completely different are most welcome to use
> our stuff and do it themselves.
>
> Deal?
>

Is there some specific disagreement this is referring to, or just a general "proposed ground rules" statement?

On Tuesday, 8 April 2014 at 22:06:51 UTC, Nick Sabalausky wrote:
> On 4/8/2014 11:49 AM, Steve Teale wrote:
>> On Tuesday, 8 April 2014 at 14:10:19 UTC, simendsjo wrote:

>>
>> Those who want something completely different are most welcome to use
>> our stuff and do it themselves.
>>
>> Deal?
>>
>
> Is there some specific disagreement this is referring to, or just a general "proposed ground rules" statement?

Ground rules-but rules are meant to be broken ;=)

Steve