World: r3wp

Uniserve is one of our base framework  (both for internal use and 
for our customers), so we're working on it actively.

I'll release it as soon as I find some time to update the docs and 
package it.

Doc,  I'm not sure if you've got this yet or not,  but we found a 
bug where the 'read-packet function's buffer was not getting expanded 
properly which was causing it to truncate some of our data.  To fix 
this problem then we added a local variable and added these lines:

tmp: pl/cache
pl/cache: make binary! pl/buf-size
system/words/insert tail pl/cache tmp

after this line:

pl/buffer: make binary! pl/buf-size: packet-len

Hi Ammon, it is possible that there's some issue maintainin the 2 
buffers size in sync. I've added your patch (with small modifications) 
to the current code.

v1.0.2 including Ammon patch uploaded.

Thanks!

the "Bad handshake" issue appears randomly when logging to the server. 
It looks like it's related to the server side.

Ok, I've found a workaround for this problem. I still have a 1045 
User deny random error to fix (almost done) and make a new release 
tomorrow. 1.0 official release is now very close.

After tracking down the problem, here's the explanation of the random 
1043 (bad handshake) and 1045 (access deny) error on connecting to 
the server :

The v3.xx protocol is flawed. The scrambled password is sent to the 
server as a zero terminated string. But the scrambling method, sometimes 
contains a 00 byte. The server then, cuts the password prematuraly 
(error 1043) or if the zero is at the beginning of the string, considers 
that the user didn't provide any password (error 1045).

The new 4.1.1+ protocol fixes that kind of issue by sending the string 
size first (like in Pascal language). The current driver doesn't 
implement the new protocol. This will be the main feature of the 
v2 of the MySQL driver.

thanks for the explanation and for your research. the terminating 
character strategy looks like fundamentally flawed, because it causes 
problems of this kind too often to be considered useful, at least 
in my opinion

I agree, I never use this approach when I design a new protocol. 
It leads to error and it's harder to handle on the receiver side 
because you don't know how much data you're waiting for.

So v 1.0 will have to live with those occassional errors? If so, 
we should go for 1.0 and claim it is a feature, not a bug :-)

v1.0.3 uploaded. That's my new candidate for 1.0. The connection 
process is now rock solid! I've stressed it with 20,000 connections 
without troubles. The protocol flaw for password is now silently 
handled by the driver by reconnecting to the server.

With v3.x.y servers, there's still sometimes connections errors 1045 
that shouldn't happen. I guess that's related to some encryption 
implementation difference between my client and v3 servers. Workaround 
for this, is catching error! values when connecting and retrying 
the connection if the user/pass is fixed and should be able to connect 
to the server (proper right set in 'mysql' tables).

There is one email on ml, reporting still having problems with latest 
version - his name is Alain Goye, and he says that his error is not 
random, but deterministic, dunno what he means, Anton trying to find 
out more info ...

Doc, one forgotten probe probably ... go look into do-handshake function 
and the part where you send-packet port probe rejoin [] ... the probe 
should not be there probably ...

Uploaded the last version without the "probe". :-)

Tried to reproduce Alain's problem without success. I've even created 
new users with server v4.1-16 and can log in without any error.

hi guys, does the latest driver work with MySQL v5.0, or are there 
any known issues?

the do work - tested with 5.0.18 here,, but only sporadically, not 
heavy-tested ....

Apparently MySQL 5 has a datatype that isn't defined in the protocol, 
adding this line seems to work just fine:

defs/types 246 decimal

Thanks Ammon, I'll add it for the 1.0 release.

I get a strange bug where I, every time I do a query, some old data 
is sent back to me

with 1.0.3 and MySQL 5.x.x

actually it happens every time I try to query an empty table

This sounds just like the issue we were talking about in SQLite group. 
You probably need to copy the results and maybe also clear the strings 
returned by the query.

I'm not sure how to do that... I 'insert a query to a port and 'copy 
the result back out from that port... I can't control that, can I?

So if your code looks like this:
	insert port sql-query
	result: copy port
What does result contain ?

(I suspect we are talking about COPY in different places. I don't 
mean the COPY from the port.)

fixed it! I'm not sure exactly how it works, because I do really 
copy the value to 'result like you describe, but the variable is 
local to a function. a CLEAR RESULT after RESULT: COPY PORT solved 
it

thanks for the tip :-)

Great !  but... you haven't told me what result contains. Is it a 
string ?

Ahh... also show me what the function looks like. Is it like this:
	func [
		/local result
	][
		insert port sql-query
		result: copy port
	]

Remember that COPY actually calls the COPY function in the scheme 
handler. (probably, I haven't looked at MySQL scheme).
Therefore maybe what you want is actually:

	result: copy copy port


The theory being that the first COPY provides you with the result 
string from inside the scheme handler (but the scheme still hangs 
on to it), and the second COPY works as usual in rebol (actually 
makes a copy).

Couldn't reproduce the bug...When an empty set is returned, the driver 
returns an literal empty block! value. This shouldn't be an issue 
as long as you don't modify the returned value. Anyway to avoid such 
side effect, the driver now return a fresh new block!.

dockimbel: I think it only returned an incorrect block after doing 
an SQL insert operation. when doing normal select queries it would 
return an empty block! where it should, but after using SQL insert, 
empty blocks contained old values

I tried several tests, but it works well, no issue :

>> insert db "insert into regions values ('556', 'test')"
== none
>> insert db "select * from empty"
== none
>> probe copy db
[]

which mysql version? I've only seen it on 4.1 and up

4.0.16

the copy copy thing fixes it for 5.0, it seems

Ok, will try to reproduce that with a 5+ version

Just tried with v5.0.19, no problem :

is that with the fix?

>> db: open mysql://[root-:-localhost]/test
>> insert db "insert into regions values ('557', 'test')"
== none
>> insert db "select * from empty"
Yes, let me try without it

maybe it needs to get "dirty" with a few selects first... I don't 
know

Tried with several SELECT clauses, tried using partial reading with 
copy/part, still no problem...

With or without using a fresh block! value for empty set

Do you have a small example that doesn't work for you ?