encode
Discussion: core back-end vs third party ones.
Currently we support 4 back-end:
- postgres with asyncpg
- postgres with aiopg
- mysql with aiomysql
- sqlite with aoisqlite
There's an open PR for MSSQL that utilizes aioodbc, which is generic enough to support several DBs. But the question arose whether we want to bring it into the core or to move to the third-party dependency.
Currently, we don't support "external" back-ends, but there's an open ticket - https://github.com/encode/databases/issues/180.
I guess my broad preference here is not to be managing projects that include code I'm not able to test. What databases can aioodbc be used against?
It's also possible that maybe we could be more lenient on including stuff in core at the moment, but look at switch some stuff out to third party packages at a later date if it feels needed?
Also what options might we have for packages automatically registering themselves as an extension?
@tomchristie
What databases can aioodbc be used against?
It can support at least SQLite, MySQL, PostgreSQL, MSSQL and Oracle. But it follows ODBC specs in general, so the list might be wider, but with less support for certain DB specific features.
what options might we have for packages automatically registering themselves as an extension?
I haven't thought about that, but my idea is just to prepare API for this. It currently picks the backend from the DB dsn, and it's not possible to pass any other back-ends without re-writing the core.
Say roughly, something like:
from custom_backend import CustomBackEnd
database = Database(url, backend=CustomBackEnd)
It's not automatic, but explicit and straightforward.
Yup that seems pretty sensible. Hard to see any reason we wouldn't want to go for that.
Perhaps it'd make sense to do alongside having a third party driver available. Would the aioodbc driver be a good candidate for a third party driver?
Great news! Yes, I think aioodbc should be a good candidate indeed as well as a good example. Shall we run it under encode as well?
No, I'd rather we distribute out any other drivers across repos outside of encode. (If they're going to be in encode I'd rather they were just included in this package in the first place.) That'll spread maintenance load to whoever's actually interested in maintaining them.