8000 sequential query does not work · Issue #1 · mysqljs/mysql · GitHub
[go: up one dir, main page]
Skip to content

sequential query does not work #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
itunali opened this issue Aug 16, 2010 · 3 comments
Closed

sequential query does not work #1

itunali opened this issue Aug 16, 2010 · 3 comments

Comments

@itunali
Copy link
itunali commented Aug 16, 2010

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
Copy link
Contributor
mscdex commented Aug 22, 2010

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
Copy link
Collaborator
felixge commented Aug 22, 2010

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
Copy link
Collaborator
felixge commented Aug 22, 2010
< 9B97 tr class="d-block">

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

@code-smith code-smith mentioned this issue Jul 9, 2017
Closed
dveeden pushed a commit to dveeden/mysql that referenced this issue Jan 31, 2023
@julienschmidt
Added debug and error logging
8a6f642 
Fixed Issue mysqljs#1
myspar pushed a commit to myspar/mysql that referenced this issue Dec 21, 2023
@ltangvald
Merge pull request mysqljs#1 from ioggstream/fix-gtid-issue-oracle
9dd8a7c 
fix issue with fabric: http://bugs.mysql.com/bug.php?id=72281
myspar pushed a commit to myspar/mysql that referenced this issue Dec 21, 2023
@ltangvald
Add change from mysqljs#1 to other entrypoint scripts
bc3e14e
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@felixge @mscdex @itunali
0