New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compiler: Add Defaults support in bindings #3375
Conversation
Is this a SQLDelight feature? Like would writing
be valid HSQL? |
Yes it is valid and normal HSql |
im confused then, isn't this replacing it with |
Before the PR, all binding parameter are replaced with |
sqldelight-compiler/src/main/kotlin/app/cash/sqldelight/core/compiler/QueryGenerator.kt
Show resolved
Hide resolved
This PR needs a mixin, specified in sql-psi. I will try to add the mixin to sqldelight. |
Yes, this was the problem |
Oh I see, you're doing the opposite of what I was saying: before it was replacing DEFAULT with ?, this PR keeps it as DEFAULT |
Exactly, this is the reason for the PR. |
...ler/dialect/src/main/kotlin/app/cash/sqldelight/dialect/grammar/mixins/BindParameterMixin.kt
Show resolved
Hide resolved
...in/src/test/integration-hsql/src/main/sqldelight/app/cash/sqldelight/hsql/integration/Dog.sq
Outdated
Show resolved
Hide resolved
dialects/hsql/src/main/kotlin/app/cash/sqldelight/dialects/hsql/grammar/hsql.bnf
Outdated
Show resolved
Hide resolved
...ts/postgresql/src/main/kotlin/app/cash/sqldelight/dialects/postgresql/grammar/PostgreSql.bnf
Outdated
Show resolved
Hide resolved
I will review this at some point it just requires more brain power than the easy PRs and I am short on brain power atm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also okay exploring the suggested change myself later if you've spun off this
sqldelight-compiler/src/main/kotlin/app/cash/sqldelight/core/compiler/QueryGenerator.kt
Outdated
Show resolved
Hide resolved
Add test for PostgreSQL Spotless Move mixin to sqldelight Use mixin instead Don't add DEFAULT bindings to query Fix DEFAULT in binding
Fix docker test dependencies
Add test for PostgreSQL Spotless Move mixin to sqldelight Use mixin instead Don't add DEFAULT bindings to query Fix DEFAULT in binding
Fix docker test dependencies
abstract class BindParameterMixin(node: ASTNode) : BindParameterMixin(node) { | ||
override fun replaceWith(isAsync: Boolean, index: Int): String = when { | ||
text == "DEFAULT" -> text | ||
isAsync -> "$$index" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this feels like a driver implementation detail, that specifically for R2DBC we need indexed parameters.
We're getting closer and I'm very happy to have functioning tests for this stuff now, so this is really the only thing I'm still hung up on
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not only r2dbc. Postgres native needs indexed parameters too: https://github.com/hfhbd/postgres-native-sqldelight/blob/1a82ac52d6ab6246644fe8216932fd348afd1a9a/postgres-native-sqldelight-driver/src/commonMain/kotlin/app/softwork/sqldelight/postgresdriver/PostgresNativeDriver.kt#L165
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kinda like that approach more, doing it at the driver level
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But at driver level you only have strings. So "SELECT '?'" or "LIKE 'foo?%'" does not work. (Except using sql-psi at driver level during runtime again before executing each stmt)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright, I buy that
last suggestion then: could we just always replace arguments for the postgres driver with their indexed argument, even if its not the async driver? So that parameter can be removed and we're just saying for this dialect this is the expected parameter format
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What parameter do you want to drop?
index => How do you want to do this? Hardcode a check in sqldelight-core to replace the parameter wildcard with a specific string for postgresql only?
isAsync => I have to check it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As expected, using $1
does not work on JDBC and results in an org.postgresql.util.PSQLException, because you try to bind a parameter to an unknown one:
In JDBC, the question mark (?) is the placeholder for the positional parameters of a PreparedStatement. There are, however, a number of PostgreSQL® operators that contain a question mark. To keep such question marks in an SQL statement from being interpreted as positional parameters, use two question marks ( ?? ) as escape sequence. You can also use this escape sequence in a Statement , but that is not required. Specifically only in a Statement a single ( ? ) can be used as an operator.
https://jdbc.postgresql.org/documentation/query/#using-the-statement-or-preparedstatement-interface
But I removed some useless check/binding implementations because I already check for DEFAULT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good. I'm still wishing that this logic was in the driver somewhere instead of the dialect since it looks like a driver constraint, not a postgres one, but lets just merge to fix the underlying issue and then if it becomes a problem later we can revisit.
This reverts commit 4c0f582.
Fixes #3374
Fixes #3526