Closed ronkorving closed 13 years ago
Just wondering....wouldn't it make sense to just not rely on the queuing and use callback logic instead? E.g. instead of:
connect query query end
do:
connect query query end
(where indentation implies that you're calling the next query in the callback of the previous query).
I've found the queuing behavior to be useful for simple cases, but problematic for cases where you need to do something conditionally. E.g. I had code that did this:
connect query query end
which got me into all sorts of trouble (because the end was queued prior to the second nested query being executed). Sound like you have a similar problem with transactions.
Yes. The end (wether it be rollback or commit) will always have to be part of a callback. As much as I love Node's asynchronous nature, for typical SQL use cases it can be quite annoying, and I don't get the impression that anybody has come up with real elegant solutions for this.
Duplicate of #59. This will be addressed by providing multiple statement support.
Check out this... https://github.com/bminer/node-mysql-queues
I have added transaction support to node-mysql. Check out this project:
We've been doing our own implementation of transaction support wrapped around node-mysql. It's quite a tough thing to get right, and easy to use. It is natural behavior in node-mysql that queries are queued. The problem is that queuing a COMMIT onto a list of queries, means that if there is an error with a query inside the transaction, the successful part of the transition will still be committed. The decision to issue a ROLLBACK or a COMMIT can only be made after all queries that needed executing have finished.
For this reason, we would love to either have some awesome native transaction support that deals with these issues, OR have the following implemented:
nodeMysql.queueCallback(function myCallback() {});
Which would append the callback to the end of the query stack.
If we had this, we could queue a callback that when called can decide whether to COMMIT or ROLLBACK based on any previously registered error state.