World: r3wp

I've just run a big stress test with 40'000+ requests generating 
around 2Gb of traffic without any trouble ! No bad handshakes anymore 
if you're using v5+ tables and new passwords.

I'm testing it over an ADSL connection now against a V5 server with 
multiple users. no trouble at all.

I've just uploaded v1.06 which adds support for a few missing new 
datatypes.

http://softinnov.org/tmp/mysql-protocol.r

downloading.., thank you!

Thanks!

BTW, an old question I continue to ask but how do you all handle 
checking whether a port is open or not?

This should work: either insert db-port [ping] [print "port opened"][print 
"port closed"]

If it is at reading data : try [copy db-port] should work too.

there are times when the connection to the database won't wake up 
after hours of sleep and the application locks. this also happens 
with mysql-admin, but I wonder if it really is server or a client 
side problem.

My driver should reconnect automatically is the connection is closed 
by the server when you send a new request even after hours of sleeping. 
I need to test that with a v5 server to see if it behaves as expected.

Thank you. With the old protocol I would sometimes get  an error 
 (and exit from the program) when I inserted into a closed port. 
I will give these a shot.

I can see that mysql console has no problem in reconnecting where 
rebol and mysql-admin fail

Doing the following test works for me (v5 server) :

1) Load the REBOL mysql console : do %mysql.r
2) Connect to the server
3) Command: show tables
4) result ok
5) Stop/Start the server
6) Command: show tables
7) result ok (the driver has reconnected transparently)

Erratum: replace the step : do %mysql.r by :

do %mysql-protocol.r
do %mysql-client.r
mysql

Doc, any news on when will you go v1.0 with the postgress driver?

Great Doc!
I didn't believe you'd ever call a version worthy of 1.0 ;-)

It takes, at least, 4 for years of beta-testing to become 1.0 ;-))

and intense bugfixing sessions 4 days before releasing 1.0 :-)

Postgresql: Don't know, I may work on it this summer for a customer, 
so I may release new versions. I didn't had much feedback on this 
product, maybe too few users in the REBOL community...?

was it oldes who made some fixes for the postgres driver?

If anyone got useful patches to postgres driver, please publish them 
here.

posted by oldes 24 November

I like async internally, and anyway I remember I had problems with 
the non-asyns async - I think sometimes it was not able detect if 
the client closed connection or something like that, and i have my 
async version of postgres I'm using. I want new build of Core with 
async and rebocodes so much:(

we will have to wait for A3:( but I still use the old alfa version 
of Rebol/Core with this script: http://oldes.multimedia.cz/rss/projects/a-pgsql/latest/a-pgsql.r

A3 = R3

why do you presume R3 will contain async networking?

or multitasking (I hope)

what would be the point of R3 if it didn't contain threading?

to entertain community somehow so we do not complain to much? ;o)

If some of you still have troubles connecting to a v4+ MySQL server 
with the last driver v1.0.6, please give a try to a new beta version 
(1.0.7) found here : http://softinnov.org/tmp/mysql-protocol.r

If you've set up your MySQL server using a PHP tool like phpMyAdmin, 
your users are probably created with the OLD_PASSWORD mode, even 
if you're using v5+ servers (it's a PHP issue). My driver v1.0.7 
should allow you to connect flawlessly to such configured server. 
Please try it and give me some feedback.

docKimble, I just thought of something: what if, for MySQL, a time 
out is not the same as reconnecting to a restarted server?

I don't understand your question. Could you explain a little more 
?

if you restart mysql, there are no prior connections to handle for 
mysql. if your connection times out, I wonder if mysql then does 
something different to create the connection again.

that wasn't clear enough...

If you restart mysql, there are no prior connections to handle for 
mysql, thus the test above works every time. If your connection times 
out, I wonder if mysql then does something different to create the 
connection again and then sometimes fails.

I would be easier to understand if you replace the word "mysql", 
by either "client" or "server". ;-) But, anyway, I think I got the 
picture.

ah :-)

If your server goes down, your remaining client connections will 
timeout and generate an error value.

When a new request is sent through a timeout-ed connection, my driver 
will close the port and try to reconnect to the server. It tries 
3 time and if it fails, generates an error.

ok

If the server is up again at the time of the reconnection, it should 
be ok.

I never tested such case deeply, so they might be some bugs/issue 
that I didn't saw.

maybe I'll do some tests when I get time :-)

Thanks, that would help me know if this feature works as expected.

I am using mysql-wrapper.r . In function db-last-insert-id there 
should be one less "first" command to get the result. I think this 
is a bug, pls confirm

does anybody have an example using db-cached-query ? thanks