{"action":"created","issue":{"url":"https://api.github.com/repos/mysqljs/mysql/issues/274","repository_url":"https://api.github.com/repos/mysqljs/mysql","labels_url":"https://api.github.com/repos/mysqljs/mysql/issues/274/labels{/name}","comments_url":"https://api.github.com/repos/mysqljs/mysql/issues/274/comments","events_url":"https://api.github.com/repos/mysqljs/mysql/issues/274/events","html_url":"https://github.com/mysqljs/mysql/issues/274","id":6209234,"number":274,"title":"true server-side Prepared Statements","user":{"login":"jokeyrhyme","id":479816,"avatar_url":"https://avatars.githubusercontent.com/u/479816?v=3","gravatar_id":"","url":"https://api.github.com/users/jokeyrhyme","html_url":"https://github.com/jokeyrhyme","followers_url":"https://api.github.com/users/jokeyrhyme/followers","following_url":"https://api.github.com/users/jokeyrhyme/following{/other_user}","gists_url":"https://api.github.com/users/jokeyrhyme/gists{/gist_id}","starred_url":"https://api.github.com/users/jokeyrhyme/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jokeyrhyme/subscriptions","organizations_url":"https://api.github.com/users/jokeyrhyme/orgs","repos_url":"https://api.github.com/users/jokeyrhyme/repos","events_url":"https://api.github.com/users/jokeyrhyme/events{/privacy}","received_events_url":"https://api.github.com/users/jokeyrhyme/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/mysqljs/mysql/labels/feature","name":"feature","color":"058aff"},{"url":"https://api.github.com/repos/mysqljs/mysql/labels/help%20wanted","name":"help wanted","color":"5319e7"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":81,"created_at":"2012-08-14T06:26:39Z","updated_at":"2016-09-17T14:32:29Z","closed_at":null,"body":"I noticed that Prepared Statements seem to be emulated client-side by escaping certain characters.\n\nAny plans to fully support service-side Prepared Statements? This can be done via the binary protocol, but there's a slower SQL-based approach available for non-binary clients:\nhttp://dev.mysql.com/doc/refman/5.5/en/sql-syntax-prepared-statements.html"},"comment":{"url":"https://api.github.com/repos/mysqljs/mysql/issues/comments/247776181","html_url":"https://github.com/mysqljs/mysql/issues/274#issuecomment-247776181","issue_url":"https://api.github.com/repos/mysqljs/mysql/issues/274","id":247776181,"user":{"login":"Redsandro","id":1702193,"avatar_url":"https://avatars.githubusercontent.com/u/1702193?v=3","gravatar_id":"","url":"https://api.github.com/users/Redsandro","html_url":"https://github.com/Redsandro","followers_url":"https://api.github.com/users/Redsandro/followers","following_url":"https://api.github.com/users/Redsandro/following{/other_user}","gists_url":"https://api.github.com/users/Redsandro/gists{/gist_id}","starred_url":"https://api.github.com/users/Redsandro/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Redsandro/subscriptions","organizations_url":"https://api.github.com/users/Redsandro/orgs","repos_url":"https://api.github.com/users/Redsandro/repos","events_url":"https://api.github.com/users/Redsandro/events{/privacy}","received_events_url":"https://api.github.com/users/Redsandro/received_events","type":"User","site_admin":false},"created_at":"2016-09-17T14:32:28Z","updated_at":"2016-09-17T14:32:28Z","body":"@sidorares \r\n> this is probably not the case. ( mostly because of serial nature of protocol ) 10000x 100batched non-prepared is going to be way faster than 1m prepared.\r\n\r\nReally? Hmm, in that case I'm a tad bit disappointed by the speed, but perhaps the server is to blame. I'm talking about _\"Nested arrays are turned into grouped lists (for bulk inserts)\"_. I assumed the translating would add some overhead.\r\n\r\n> Even more faster way is to use LOAD INFILE (basically whole 1m in one batch with very little overhead)\r\n\r\nUnfortunately in my particular case I can't (or don't want to) do this, because I can only generate a 100-ish records at a time, depending on input data. Right now it's very resilient. It just waits if the table is locked (in case something else does a big query), data is in the table directly and isn't delayed by a day writing an intermediate `INFILE` first, and it picks up where it left off.\r\n\r\nI have experimented with node not waiting for the `INSERT` to call back, but then the queue can fill up and choke the script.\r\n\r\n> I might have a look again and see how much work left\r\n\r\nI applaud this! :+1: \r\nAlthough as you pointed out, I might not benefit from this in my particular use case. But I'm looking forward to experimenting with this."}}
{"actor":{"display_login":"Redsandro"}}