Re: [Twisted-Python] Case for an Async MySQL Driver?
Nick Arnett wrote:
Anybody want to offer more about how this might look? I don't know if I can fit it into my work, but it would be a terrific addition to my toolbox (I have many thousands of lines of Python talking to MySQL). And I suppose it would offer the excuse I've been needing to ask our CEO about his thoughts on open-sourcing parts of our code.
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.
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? Seun Osewa wrote:
Nick Arnett wrote:
Anybody want to offer more about how this might look? I don't know if I can fit it into my work, but it would be a terrific addition to my toolbox (I have many thousands of lines of Python talking to MySQL). And I suppose it would offer the excuse I've been needing to ask our CEO about his thoughts on open-sourcing parts of our code.
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.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
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