the MySql driver 1.10 appears to be broken in 3.6g, due to the changes in Socket and SimpleClientSocket. (SimpleClientSocket was renamed to OldSimpleClientSocket and Socket was renamed to OldSocket). Simply changing the MySql driver to use the old classes is not sufficient because then SocketStream breaks. There may be more to it but that's as far as I got.
Is this a known problem or has it been fixed already?
On Sat, 25 Oct 2003 22:21:09 -0400, ar wrote:
the MySql driver 1.10 appears to be broken in 3.6g, due to the changes in Socket and SimpleClientSocket. (SimpleClientSocket was renamed to OldSimpleClientSocket and Socket was renamed to OldSocket). Simply changing the MySql driver to use the old classes is not sufficient because then SocketStream breaks. There may be more to it but that's as far as I got.
Is this a known problem or has it been fixed already?
I made it work with some minor changes. I've gotten back a couple of query results, that's as far as I've tested. The timeout condition has definitely not been tested. But it shows that the impact of the 3.6 socket changes might not be too far reaching on the MySql driver.
socket _ Socket new "was SimpleClientSocket"
connectTo: (connectionSpec host)
port: (connectionSpec port).
(socket waitForConnectionFor: Socket standardDeadline) "was waitForConnectionUntil:"
"ifFalse: [Transcript cr; show: 'not connected']". "commented for 3.6"
I know nothing of the channels for reporting/fixing bugs so hopefully this will trickle back to where it should.
-alan r.
On Saturday, October 25, 2003, at 07:58 PM, ar wrote:
I know nothing of the channels for reporting/fixing bugs so hopefully this will trickle back to where it should.
Well, I guess I'm nominally the maintainer for this package, but I'm not using MySQL anymore, so I haven't been in any hurry to update it for the network rewrite. The main issue, of course, is that the driver depends on Bolot's version of SocketStream which is completely unrelated to Michael's implementation.
Which version of SocketStream did you get to work?
Colin
On Sun, 26 Oct 2003 01:48:40 -0700, Colin Putney wrote:
On Saturday, October 25, 2003, at 07:58 PM, ar wrote:
I know nothing of the channels for reporting/fixing bugs so hopefully this will trickle back to where it should.
Well, I guess I'm nominally the maintainer for this package, but I'm not using MySQL anymore, so I haven't been in any hurry to update it for the network rewrite. The main issue, of course, is that the driver depends on Bolot's version of SocketStream which is completely unrelated to Michael's implementation.
Which version of SocketStream did you get to work?
Colin
I am sufficiently remote from recent discussions & developments in Squeak that I have only just become aware that there even was a network rewrite.
But I guess the answer is Michael's; I am using 3.6g and haven't installed Commanche, which I assume is where Bolot's version would come in from because I saw a post from Avi saying that he renamed it to KomSocketSession in Commanche 5 in order to avoid a conflict with the network rewrite.
Since my previous post I've done a lot more testing with my change and the driver is apparently working fine; but I have no idea what would happen on a network timeout (nor how it behaves pre 3.6 for that matter - it looks like all it used to do was write a line in the Transcript; whereas maybe now an exception will be thrown. I think before, I may have just gotten errors further downstream on a network timeout).
Anyway if they (SocketStream versions) are that different it is impressive that the driver still works; esp since Avi says that methods like #upTo: have annoyingly different semantics. Anyway, I haven't noticed any bytes dropped off my data or anything :)
ar wrote:
Anyway if they (SocketStream versions) are that different it is impressive that the driver still works; esp since Avi says that methods like #upTo: have annoyingly different semantics. Anyway, I haven't noticed any bytes dropped off my data or anything :)
That is indeed impressive. If I were you, I would look at any sends to #upTo:, #upToAll:, and #match:, just to make sure - those are the methods I remember having significant differences.
Stephen Pair can probably lend some insight here, since he ported Comanche to 3.6 and would have had to address the same issues.
It's not that the MySQL package is just including its own SocketStream, and you're thus breaking every other network client, is it?
Avi
Hi guys!
Avi Bryant avi@beta4.com wrote:
ar wrote:
Anyway if they (SocketStream versions) are that different it is impressive that the driver still works; esp since Avi says that methods like #upTo: have annoyingly different semantics. Anyway, I haven't noticed any bytes dropped off my data or anything :)
That is indeed impressive. If I were you, I would look at any sends to #upTo:, #upToAll:, and #match:, just to make sure - those are the methods I remember having significant differences.
I am just porting HttpView to Kom6.2 and 3.6 networking and stumbled upon a few things that wasn't functioning. One problem was that #match: isn't in 3.6-SocketStream. I have implemented that one though, and some other little thing I can't remember right now.
#upToAll: can of course be used instead but it is quite different from Bolot-match:. And Bolot-match is slightly different than PositionableStream-match:.
Stephen Pair can probably lend some insight here, since he ported Comanche to 3.6 and would have had to address the same issues.
It's not that the MySQL package is just including its own SocketStream, and you're thus breaking every other network client, is it?
That is a good thing to check. ;-)
Avi
Anyway, I will be feeding my stuff back into Kom and the base image as appropriate.
regards, Göran
ar wrote:
I made it work with some minor changes. I've gotten back a couple of query results, that's as far as I've tested. The timeout condition has definitely not been tested. But it shows that the impact of the 3.6 socket changes might not be too far reaching on the MySql driver.
Additionally, in these days, some methods like
new ^ self basicNew
have to be inserted because the JdmMySQL-Classes dont expect Object to auto-initialize.
Cheerio, Markus
squeak-dev@lists.squeakfoundation.org
-
ar -
Avi Bryant -
Colin Putney -
goran.krampe＠bluefish.se -
Markus Fritsche