PLANNING: sql-psi 1.0

[AlecKazakova]

The main feature here is to have the individual dialects be their own artifacts, with a net result of being able to do something like this in sqldelight:

sqldelight {
  MyDatabase {
    dialect = "com.cashapp.sql.dialects:sqlite-3.24:1.0.0"
  }
}

sql-psi would become the API and ANSI-SQL grammar which sqldelight depends on, and individual dialects would be able to provide:

• parser rules (using https://github.com/AlecStrong/Grammar-Kit-Composer)
• exposed functions with types (https://github.com/cashapp/sqldelight/blob/master/sqldelight-compiler/src/main/kotlin/com/squareup/sqldelight/core/lang/util/ExprUtil.kt#L139)
• expression extension types (https://github.com/AlecStrong/sql-psi/pull/116/files)
• column metadata including:
  • type (https://github.com/cashapp/sqldelight/blob/master/sqldelight-compiler/src/main/kotlin/com/squareup/sqldelight/core/lang/psi/sqlTypeName.kt)
  • has default (https://github.com/AlecStrong/sql-psi/blob/master/core/src/main/kotlin/com/alecstrong/sql/psi/core/columnDef.kt)
• some java SPI for loading the grammar from sqldelight and initializing it (also overriding it with sqldelight-specific rules)
• subclass of sqldelight-runtime and SqlResultSet with additional getters (like getBoolean for postgres)
• additional runtimes for commonly used adapters ([PostgreSQL] Retrieve NUMERIC and DECIMAL as a more compatible Kotlin type sqldelight#1882)
• tests that verify the dialect will be compatible with sqldelight

As part of this we probably want to publish tests in sql-psi as well so that individual grammars can just run the existing sql test suite.

[AlecKazakova]

I think these are probably the next steps:

• Iterate on grammar-kit-composer to support adding tokens and clean up the process of overriding rules
• Figure out how to dynamically change the SQLDelight IntelliJ plugin's classpath (we'll need to do this for the IDE to understand dialects, since you'll specify the dialect in gradle and then the intellij plugin will somehow need to load that dialect into its classpath)
• Create a new branch on sqldelight which tracks the sql-psi snapshot where we start working on pruning out the dialect stuff in sqldelight. We could probably just use sql-psi-dev for this.
  • I like this because it still enables other contributions to sqldelight master, and a potential 1.5.1 release if there are issues we need to fix.
  • We should start building the dialects in sqldelight so its easier to make changes both to sqldelight's compiler/runtime and the dialect and test them in tandem. Later on if we wanted to move them out (like if you want to host the postgres dialect veyndan) we can do that

i think since postgres is the dialect that has a bunch of bugs blocked by this we start with that so we can make sure we're moving in the right direction. I think we start by creating some new modules:

sqldelight
--drivers
----jdbc-driver
----postgres-driver (*new*)
--dialects (*new*)
----postgres-dialect (*new*)
--sqldelight-compiler
--sqldelight-gradle-plugin
--sqldelight-idea-plugin

and copy/paste the existing postgres folder from sql-psi into that module. I assume a bunch of things will go red about stuff being internal - we should just make all those things public and then we can target the snapshot build. Then from there we can start pulling the postgres-specific code in sqldelight-compiler into the postgres dialect.

I think using the gradle testkit integration tests in sqldelight-gradle-plugin would be a major pain in the ass, so I think we write integration tests by using composite builds:

sqldelight
--dialects
----postgres-dialect
------integration-tests
--------build.gradle
--------settings.gradle

in dialects/postgres-dialect/integration-tests/build.gradle

buildscript {
  dependencies {
    classpath "com.squareup.sqldelight:gradle-plugin"
  }
}

apply plugin: "com.squareup.sqldelight"

sqldelight {
  Database {
    dialect "com.squareup.sqldelight:postgres-dialect"
  }
}

in dialects/postgres-dialect/integration-tests/settings.gradle

includeBuild("../../../") {
  dependencySubstitution {
    substitute module("com.squareup.sqldelight:gradle-plugin") with project(":sqldelight-gradle-plugin")
    substitute module("com.squareup.sqldelight:postgres-dialect") with project(":dialects:postgres-dialect")
  }
}

I'm pretty confident in that approach making it the easiest to work on sqldelight 2.0, but I am less confident about the grammar/ide stuff - so those are going to be my initial focus once I switch back on to working on sqldelight.

[AlecKazakova]

The postgres-dialect will need to have a codegen component to it that ensures that all references to SqlDriver in the generated code are instead PostgreSqlJdbcDriver, and then we can start adding all the APIs to that driver (like getBoolean) and use them in the generated code.