Separate Dialect and Connector about tortoise-orm HOT 4 CLOSED

Hi
In case of ODBC, is it really possible to implement all features that native driver implements?
I am not really familiar with working through ODBC, but I always thought that it applies certain restrictions on how much of API you could use.

And implementing such flexible function could lead to the problem that users won't really know which driver are they using right now, but results could vary based on what backend was decided to be used. Such behaviour could lead to heisenbugs, which are worst kind of bugs 😄

Regarding using ODBC engine at all - community (or we, as part of community) could just implement ODBC backend and use it.

from tortoise-orm.

ODBC is only a common subset, so I assume that some funtionality will not work the same way.
We won't know until we actually test it though. It could be horrible, or it could just work fine.

We still need to separate dialect and connector to make it clean to add (or support adding) GIS dialects. and until that gets off the ground, we might as well test using different drivers, e.g. asyncpg and aiopg.

Then it should be possible to add odbc at a later stage. (even as an external project).

from tortoise-orm.

Could do DB capabilities as part of this, as your ODBC question raised a good point that the connector may support different features, so the capabilities may need to be different for each combination... 🤔

from tortoise-orm.

Hello, I would like to use ODBC as it allows async Oracle connections. Could you point me in the right direction to start work on "... the community (or we, as part of community) could just implement ODBC backend and use it."

from tortoise-orm.