Asynchronous DBAPI

[methane (Inada Naoki)]

@smurfix

On the other hand: how much boilerplate do you require the user of an async interface to use? If the database is unable to accept a kill command while it’s flooding you with a runaway SELECT , of course await result.kill() (or simply falling off the end of the SELECT’s async context while there are unread records) needs to grab another connection from the pool to send the appropriate message … we’re not going to force the user to manually grab a new connection from the pool for that, esp. as another database might forbid doing that from another connection.

Pool can support it. Users don’t need to check another connection out and call new_con.kill(another_con.thread_id) manually. Pool may do it automatically instead. So there are no boilerplate code in applications.

@smurfix

A database driver that needs a separate connection in order to abort a runaway SELECT requires access to the pool.

• When another connection is not required to cancel a running query, DB-API driver can support it directly.
• When another connection is necessary to cancel a running query, DB-API driver may not support automatic canceling. Canceling a running query is implemented in Pool instead.

If we need to standardize it in async DB-API, these APIs should be added:

• Query that the driver supports automatic canceling a query. It may be similar to the threadsafe attribute. (Options are: No, Yes, Yes (but uses another connection))
• Option to enable/disable automatic cancellation. (autocancel=False)
• API to cancel the query executed from another connection. (e.g. Connection.kill(token))
• API to get some “token” (query token, or connection token) to cancel the query from another connection. (e.g. cursor.kill_token())

But I’m not so interested in autocancelling. We have some production applications in Go and Python and live without autocancelling.