Custom SQL support

To allow odd requirements, or using special SQL syntax that is not yet supported (or may never be) by Tortoise ORM we should provide a simple, clean, custom SQL interface.

How do we identify the connection?

Is Tortoise.get_connection("models") adequate?

Currently the connection used execute() function accepts RAW SQL, and returns data in a RAW format (dependant on the DB driver)

These functions are used internally by the ORM itself. We should privatise these, and provide standard public functions that have a well-defined interface.

How do we format parameters?

Since parametrized queries are all handled very differently for each DB we support, we should do an intermediate representation and support that. Possibly just adapt the same {field} format that SQLAlchemy ORM has and map those to the right parameter format for the local db?

How do we handle parameters?

Named parameters only. For single, should it be kwarg based: execute("<SQL>", ...) or dict based: execute("<SQL>", {...}) ? For bulk operations we can only accept a list of dicts each containing I would make it ALWAYS just accept a dict

[gdmoore]

It’s definitely a “last resort” feature. For example Pony-orm doesn’t support Python enums. You can write a converter to create the model initially, but every query you write will be broken since it doesn’t know how to serialize an enum. In a previous project we worked around it by using raw_sql for only the portion of the query involving the enum.

None of that applies to tortoise but I’m sure there will be the occasional weird use case someone has.

Supporting it in both F and Q objects would probably be great.

[lntuition]

Yeah. I agree that it have to be limited use. I think expand and refactor current F and Q to support custom SQL is good choice.