Also, maybe there should be a check for stray `?` ...
# komapper
d
Also, maybe there should be a check for stray
?
in KomapperCommands(/templates?), they don't seem to make sense... and one might forget a few when migrating queries to templates.
t
What does
stray
?`` mean?
d
Copy code
@KomapperCommand("""
   ....
   WHERE id = ?
   ...
""")
in a very long sql, one might forget to replace
?
with
/* ... */1
(it happened to me šŸ˜µā€šŸ’«)
This is important when migrating sql statements into Komapper (from an sql tester or another db library)
t
Thank you. I now understand what ā€œstray ?ā€ means. Testing the SQL specified in
KomapperCommand
in an SQL tool like pgAdmin might help resolve the issue.
d
So it's not possible to do that check during the ksp compiling? Just like you check the validity of the template itself...
t
With some drivers, bind variables aren’t always represented by
?
. For example, in PostgreSQL’s R2DBC driver, a format like
$1
is used instead of
?
. We don’t know which format to check for at compile time.
d
Also, it's not always possible to just copy and run the komapper command... since there's directives, partials etc... so the sql isn't always valid per-se, and when migrating lots of sql, it gets tedious to do those checks...
With some drivers, bind variables aren’t always represented by
?
. For example, in PostgreSQL’s R2DBC driver, a format like
$1
is used instead of
?
. We don’t know which format to check for at compile time.
? is for sure a culprit... but if it would be able to check for both notations, it would be better... since in any case, both wouldn't be valid in a KomapperCommand
Doesn't matter which driver...
t
In SQL Server’s R2DBC driver, bind variables take the form
@id
. Checking all formats would be difficult to maintain and could lead to false negatives, mistakenly identifying valid SQL for a particular database as invalid. If we were to perform a check, it would be better to do so at runtime, where we can determine which driver is in use, rather than at compile time. Another idea is to use an LLM application like ChatGPT for this check, which would be a convenient and effective option.
d
Yeah, I guess, maybe the only option left for this would be a ksp option to enable such a check... in general a project using Postgres won't use SQL Server (the sql syntax is different so anyways all the commands would need to be rewritten...), but I'm not sure how manageable that would be on the end of the ksp plugin... a little plus to such an option would maybe potentially enable more sql syntax checks on the commands, but I don't think that's the direction you really want to go having to maintain such options or even different ksp plugins just for these checks... I guess I'll just have to be careful...