Re: [Twisted-Python] Case for an Async MySQL Driver?
![](https://secure.gravatar.com/avatar/1c04c7b3c586a0d9763316d6706038cb.jpg?s=120&d=mm&r=g)
Nick Arnett wrote:
Here are some ideas for an async MySQL 'driver' for Twisted: 1) create or use a connection: connection = MySqlPool.connect("hostname", "username", "password") 2) send a query: d = connection.exec(["begin", "update db.stats set value=value+1 where accesses", "select * from db.important_table", "commit"]) def myCallBack (resultset): # 'results' contains the result of the last QUERY in the list of commands sent to exec. # it is empty if there's no QUERY and no error .... def myErrBack (errorval, errorstring command_id): # this is called if there's an error in executing any of the commands # command_id indicates which point in the list of commands the error occured # errorval is the error name/number, errorstring the exact result 3) close the connection: connection.close() This format allows the user to send an unlimited number of queries to be run together, thus limiting the number of callbacks necessary for a program requiring many small interactions with the database. "begin" and "end" will count as an example. This minimalistic API also allows more advanced (twisted.enterprise style) interfaces to be built on top of it. Is there any task you can think of that can't be built on top of this? (of course I've not touched the implementation details...) Regards, Seun.
![](https://secure.gravatar.com/avatar/1c04c7b3c586a0d9763316d6706038cb.jpg?s=120&d=mm&r=g)
Hi, The approach I was suggesting is to have a minimalist 'driver' API for MySQL which can be used independently (for new development of MySQL-specific projects) and yet can be easily used for MySQL support in adbapi. Correcting my earlier short outline, -> a minimalistic mysql 'driver' API shouldn't even involve a DB pool. -> The 'result' can simply be in the form of an iteratable which returns the result of each executed query in order, no need for the restriction to have only one query within a group of MySQL commands. -> However, the errBack should be called when any of queries fail, indicating how which particular query failed by giving the number of successful queries. ACTIONS conn = MySqlConnection ("hostname", "username", "password") d = conn.exec (["stmt1", "stmt2", "stmt3"]) d.addCallBack(call1) d.addErrBack(err1) conn.close() # we have finished with this connection. DEFINITION def call1(result): ... def err1 (successful_queries, errno, description): ... It appears reasonable to allow the connection constructor to block when creating the database connections ... the API user should deal with connection caching. Regards, Seun. On Thu, 28 Oct 2004 17:00:57 -0400, orbitz <orbitz@ezabel.com> wrote:
Hrm, wouldn't it be a bit nicer on programmers to use the current adbapi interface so they can just move all their code to this new mysql API?
![](https://secure.gravatar.com/avatar/1c04c7b3c586a0d9763316d6706038cb.jpg?s=120&d=mm&r=g)
Hi, The approach I was suggesting is to have a minimalist 'driver' API for MySQL which can be used independently (for new development of MySQL-specific projects) and yet can be easily used for MySQL support in adbapi. Correcting my earlier short outline, -> a minimalistic mysql 'driver' API shouldn't even involve a DB pool. -> The 'result' can simply be in the form of an iteratable which returns the result of each executed query in order, no need for the restriction to have only one query within a group of MySQL commands. -> However, the errBack should be called when any of queries fail, indicating how which particular query failed by giving the number of successful queries. ACTIONS conn = MySqlConnection ("hostname", "username", "password") d = conn.exec (["stmt1", "stmt2", "stmt3"]) d.addCallBack(call1) d.addErrBack(err1) conn.close() # we have finished with this connection. DEFINITION def call1(result): ... def err1 (successful_queries, errno, description): ... It appears reasonable to allow the connection constructor to block when creating the database connections ... the API user should deal with connection caching. Regards, Seun. On Thu, 28 Oct 2004 17:00:57 -0400, orbitz <orbitz@ezabel.com> wrote:
Hrm, wouldn't it be a bit nicer on programmers to use the current adbapi interface so they can just move all their code to this new mysql API?
participants (2)
-
orbitz
-
Seun Osewa