sequential query does not work

[itunali]

var db = new Client();
db.user = 'root';
db.password = 'root';
db.database = 'test';
db.connect();
db.query("SELECT SLEEP(1)",function(){console.log("First sleep");});
db.query("SELECT SLEEP(2)",function(){console.log("Second sleep");});
db.end();

Above script give below error;

itunali@itunali:~/nodejs$ ./bin/node my2.js
First sleep

/home/itunali/.node_libraries/mysql/query.js:42
field = this._fields[0];
^
TypeError: Cannot read property '0' of undefined
at Query._handlePacket (/home/itunali/.node_libraries/mysql/query.js:42:31)
at Client._handlePacket (/home/itunali/.node_libraries/mysql/client.js:194:14)
at Parser. (/home/itunali/.node_libraries/mysql/client.js:56:14)
at Parser.emit (events:26:26)
at Parser.write (/home/itunali/.node_libraries/mysql/parser.js:479:16)
at Stream. (/home/itunali/.node_libraries/mysql/client.js:51:16)
at Stream.emit (events:26:26)
at IOWatcher.callback (net:489:16)
at node.js:762:9

[mscdex]

I've reproduced this same issue. It does indeed happen when you perform two or more SELECTs using the same database connection. This bug is quite the showstopper :-(

It seems that FIELD_PACKET is not being emitted for subsequent SELECT queries. From my testing, it is instead receiving 4 ROW_DATA_PACKET events followed by 1 EOF_PACKET, 1 ROW_DATA_PACKET (this is the actual row in the table i'm assuming), and then 1 EOF_PACKET.

For my example I have a database called 'testdb' and two tables, 'foo' and 'bar'. Querying 'foo' (SELECT * FROM foo)works as expected, but querying 'bar' (SELECT * FROM bar) does not. The 'bar' table contains two fields: 'myid' and 'mytitle'.

I've found if I place this code right inside the beginning of the Parser.ROW_DATA_PACKET case in query.js, I am able to see the one row in the 'bar' table in the query results:
if (!this._fields) {
this._fields = ['myid', 'mytitle'];
}

With this modification, the query results contains:
[ { myid: 'def', mytitle: 'testdbbar', undefined: '' }
, { myid: 'def', mytitle: 'testdbbar', undefined: '' }
, { myid: '1', mytitle: 'Hello from bar' }
]

Hopefully this helps narrow down the problem some. I tried to find the root cause, but I am not well versed enough in the MySQL protocol to find it and this was as close as I could get to getting the actual row(s) back from the second SELECT query.

[felixge]

I'm looking into this myself right now, it's just as you describe. I added a new debug mode for the client along with a failing test case. The output is:

<- GREETING_PACKET: {"length":52,"received":52,"number":0,"type":0,"protocolVersion":10,"serverVersion":"5.1.46","threadId":4841,"scrambleBuffer":{"0":113,"1":44,"2":33,"3":97,"4":70,"5":119,"6":73,"7":70,"8":97,"9":56,"10":49,"11":47,"12":55,"13":99,"14":111,"15":39,"16":111,"17":121,"18":54,"19":64,"length":20},"serverCapabilities":63487,"serverLanguage":192,"serverStatus":2}
-> <Buffer 3b 00 00 01 cf f7 03 00 00 00 00 01 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 72 6f 6f 74 00 14 da b4 5f 0b 16 2d 2d a6 d3 66 5a 01 7e 07 7a 16 fb 09 5c be 00>
<- OK_PACKET: {"length":7,"received":7,"number":2,"type":1,"affectedRows":0,"insertId":0,"serverStatus":2,"message":"\u0000\u0000"}
-> <Buffer 22 00 00 00 03 53 45 4c 45 43 54 20 31 20 61 73 20 66 69 65 6c 64 5f 61 2c 20 32 20 61 73 20 66 69 65 6c 64 5f 62>
<- RESULT_SET_HEADER_PACKET: {"length":1,"received":1,"number":1,"type":3,"fieldCount":2}
<- FIELD_PACKET: {"length":29,"received":29,"number":2,"type":4,"catalog":"def","name":"field_a","charsetNumber":63,"fieldLength":1,"fieldType":8,"flags":129,"decimals":0}
<- FIELD_PACKET: {"length":29,"received":29,"number":3,"type":4,"catalog":"def","name":"field_b","charsetNumber":63,"fieldLength":1,"fieldType":8,"flags":129,"decimals":0}
<- EOF_PACKET: {"length":5,"received":5,"number":4,"type":5,"warningCount":0,"serverStatus":2}
<- ROW_DATA_PACKET: {"index":0,"length":4,"received":1,"number":5,"columnLength":0,"type":6}
<- EOF_PACKET: {"length":5,"received":5,"number":6,"columnLength":0,"type":5,"warningCount":0,"serverStatus":2}
-> <Buffer 14 00 00 00 03 53 45 4c 45 43 54 20 33 20 61 73 20 66 69 65 6c 64 5f 63>
<- ROW_DATA_PACKET: {"index":0,"length":1,"received":1,"number":1,"columnLength":0,"type":6}

This looks really weird, but I'll let you know once I found out what is going on.

[felixge]

Ok, that was a silly bug in the parser. Fixed in 94ce814