Swappable SQL Dialects #923
Replies: 2 comments 1 reply
-
I'm fine with limiting the scope to PostgreSQL. There are public cloud offerings for Postgres, on premises solutions and also other db products using the same protocol (e.g. CockroachDB). The Cosmos DB implementation is also product specific. |
Beta Was this translation helpful? Give feedback.
-
+1 on introducing this and focusing on Postgres as a first implementation. From an EDC perspective, we should support multiple SQL backends. |
Beta Was this translation helpful? Give feedback.
-
During the implementation of various SQL issues it emerged that it might pay off to make the SQL dialect exchangeable. The reason for this is, that different dialects offer sometimes a more neat and succinct syntax, and can even reduce the number of DB queries necessary.
For example in ANSI SQL there is no
upsert
, we'd have to do aSELECT
followed by aUPDATE
or anINSERT
, whereas some dialects offer specialized statements for this.Another example where this could come in handy is the ability to have explicit JSON type columns in Postgres.
Using the example of, say, the
SqlContractNegotiationStore
, we could have a wrapper classSqlDialect
that gets passed in through the CTor:For the
SqlDialect
interface there could be multiple implementations, for example:By default I'd suggest targeting either ANSI/ISO SQL, or PostgreSQL and prepare a way of providing other implementations for
SqlDialect
.From a timing perspective I'd recommend doing this post Milestone 3.
Beta Was this translation helpful? Give feedback.
All reactions