This is a short mind dump about custom backend implementations outside of diesel. Also this summerize the state of the oracle backend.
Given the current state of diesel it is possible to implement a new backend outside of diesel itself, as long as it meets the following points:
Insert syntax is equivalent to postgresql, because otherwise the will be no implementation of
InsertValues for ColumnInsertValue. Currently there are the following implementations inside of diesel:
- A backend specific implementation for Sqlite
- A wildcard implementation for all backend with a postgresql like sql syntax for insert statements.
Now it is not possible to add a new (backend specific) impl outside of diesel, so the only solution here is to “use” the wild card implementation. As a conequnce SupportsDefaultKeyword needs to be implemented for all new backends. (For oracle this somehow works for single element insert statements, but batch inserts and inserts with default value are broken) This is maybe fixed by the Re-Rebalancing Coherence RFC.
It is not possible to add support for some backend specific operations implemented in diesel itself. This basically boils down to that it is not possible to implement
Queryable<Oracle>for something that exists inside in diesel. In consequence this means only the common subset of sql supported by all backend (== those things with an wild card impl inside of diesel) could be supported from the outside. Again this will be solved by Re-Rebalancing Coherence RFC.
The current migration mechanism hardcodes the sql used to create the migration table. This assumes that it is possible to write create table statement that works on all backends. At least the current implementation does not work for the oracle backend. Most likely it is not possible to write a common create statement any more. This could be solved by making the create table statement somehow part of the connection implementation. See this PR for a possible implementation. A other variant would be to add the create table statement directly to the connection trait.
(To be continued as the oracle backend matures)