r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[MySQL]

Dockimbel
16-Sep-2006
[801x5]
Btw, I've released an alpha version of a new MySQL driver implementation 
: complete rewrite from scratch to be fully async under UniServe, 
 optimized decoding in speed (faster code, streaming decoding, etc...), 
supports only servers v5+. You'll find it in the latest UniServe 
archive (see UniServe group for link)
It's event based, so the API is different from the current MySQL 
driver.
Here's a short example :
uniserve/boot/no-loop/with [protocols [MySQL]]

open-port mysql://[root-:-localhost]/test [
	on-login-ok: func [db][
		insert-port db "select * from test"
	]
	on-field: func [db col][
		print ["Field:" col/name]
	]
	on-completed: func [db rows][
		probe rows
	]
]
do-events
The 'on-row and 'on-error events are currently missing.
Luca
28-Sep-2006
[806x4]
A query of mine loops and I can not understand the reason.
I gave a look to the protocol and found that :
* defrag-read port pl/buffer std-header-length

returns a 'packet-len of 108544 bytes

the next 

* defrag-read port pl/buffer packet-len


loops because the 'read within 'defrag-read  retrieves only 108543 
bytes.

Any idea on how I can deal with this problem?
Oh... I'm using MySQL 4.1.9 and I have the same problem with both 
0.9.9 and 1.0.7 protocol versions.
Dockimbel
28-Sep-2006
[810x12]
I'm aware of only one case where my protocol implementation may fail 
with a size difference of 1 byte between expected size and received 
size: that's the compression header case. This case can only happen 
when the client send a compression flag to the server. My driver 
never send such flag, so this case should never happen.
Options for testing what's wrong :
1) Try to reproduce the problem with the new async driver version 
(see the UniServe package in Uniserve! channel here).
2) Get a packet analyser tool (Ethereal for example) and try to track 
the TCP exchange on port 3306 to see what the server is really sending 
to the client.
3) Upgrade your MySQL server to latest 4.1.x version, or try with 
the latest 5.x version.
4) If all options failed, turn trace/net on, run a test, log all 
exchanges with the server and send it to me by email for analysis.
Just got an idea that should be your first thing to try :
Find the following line in the driver source :
buf-size: cache-size: 10000
and change it to :
buf-size: cache-size: 500'000
Run your tests and tell me if this fix your problem (else try the 
others options).
Luca
28-Sep-2006
[822]
Great! Changing buf-size to 500000 solved the problem.
[unknown: 9]
28-Sep-2006
[823]
Actually what I posted in Chat applies directly to MySQL, if anyone 
happens to know.
Dockimbel
28-Sep-2006
[824]
So, it looks like a bad read buffer size setting.
Luca
28-Sep-2006
[825]
The read of the buffer size is done by the 'read-int24 rule, isn't 
it?
Dockimbel
28-Sep-2006
[826x6]
True.
Luca, let's try a more cleaner fix for this issue, replace the following 
code :
;--- reading data ---
		if packet-len > pl/buf-size [

   net-log reform ["Expanding buffer, old:" pl/buf-size "new:" packet-len]
			tmp: pl/cache
			pl/buffer: make binary! pl/buf-size: packet-len
			pl/cache: make binary! pl/cache-size: pl/buf-size
			sys-insert tail pl/cache tmp
		]
by :
;--- reading data ---
		if packet-len > pl/buf-size [

   net-log reform ["Expanding buffer, old:" pl/buf-size "new:" packet-len]
			tmp: pl/cache
			pl/buffer: make binary! pl/buf-size: packet-len + length? tmp
			pl/cache: make binary! pl/cache-size: pl/buf-size
			sys-insert tail pl/cache tmp
		]
(just one line changed)
Luca
28-Sep-2006
[832]
Just a moment...
Dockimbel
28-Sep-2006
[833x2]
revert the initial buf-size to 10'000
then try again.
Luca
28-Sep-2006
[835]
Sure :-)
Dockimbel
28-Sep-2006
[836]
Going to sleep, will see the result tomorrow. Thanks for your help 
tracking this bug.
Luca
28-Sep-2006
[837x2]
Thank to help solve it :-)
Not solved using this last suggestion.
Oldes
29-Sep-2006
[839x2]
I use the protocol with MySQL 4.1.5 and 5.0.22 and never noticed 
such a problem.
But I'm not storing such a big data
Edgar
2-Oct-2006
[841]
Cal and I modified this line: 

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

to this:

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

and it works now.

Your other suggestion must have fail because tmp may have been zero 
length.
Tim
7-Oct-2006
[842x2]
I'm preparing to switch my OS to a slack partition with MySQL 4.1 
(I believe)
OOPS! didn't mean to hit ENTER. sorry. Anyway, there used to be a 
test site at http://powerofq.com- it is no longer available, I believe 
that the test module was 'mysqlprot. are those resources still available?
Webb Stone
27-Apr-2007
[844]
hi
Dockimbel
1-May-2007
[845x5]
MySQL Driver 1.1.0 will be released today. The new features are :
- There's now a new preferred way to query data, the SEND-SQL global 
function. The INSERT/COPY methods are still available for cases where 
finer-grained control or ressources optimization is required. Example:


send-sql [ /flat ] [ /named ] [ /raw ] db "SQL query or server command"
- New "named fields" mode in the driver produce recordsets with named 
field. Example :


author: send-sql/named db "SELECT id, name, birthyear FROM authors 
WHERE id=1"
print [author/name "is born in" author/birthyear]
- Support for multiple statements in queries has been added (separated 
by semicolons). Now, you can, for example :

	send-sql db read %setup.sql
I'm currently updating the documentation, I'll post in [Announce] 
when it will be ready for download.
Gregg
1-May-2007
[850]
Excellent Doc! Thanks for continuing to improve it.