-
Notifications
You must be signed in to change notification settings - Fork 209
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
add parser-based validation for JPQL, SQL, HQL snippets #1236
Comments
I'd factor out SQL is a separate issue as we don't have SQL parser and semantic token syntax highlighting for SQL. At the moment all SQL support comes from upstream extensions and syntax highlighting for SQL is somewhat restricted by what upstream extensions/plugins provide. There is no semantic tokens syntax highlighting from Boot LS provided for native SQL (but we can change that of course) |
JPQL and HQL are in with 385c35e |
SQL was the last one. Went in with fe953bd |
It looks like the SQL parser only knows about MsySQL's syntax (from the file name)? In our case we use PostreSQL-specific syntax and with the update to 4.23 I now have an error marker as the parser does not like/understand PG's type-cast syntax using
Is there a way to disable these checks? |
@pcdavid I hate to say that but the release doesn't have a setting to switch this validation off unfortunately. The setting didn't get generated and it has gone unnoticed. It should be here. The drop down has an option Please let us know how it goes. Otherwise, it might be best either don't syntax validate native query or looks at the classpath perhaps and figure out whether it is expected to be MySQL or PostGres or some other flavour of SQL... there are a couple of flavours of SQL... wonder if it makes sense to support all of them or none or some... |
For the MySQL parser issue: #1273 |
Thanks for the fast response! Strangely, I now see two such syntax issues, while there was only one with STS 4.23.0. Anyway, the new setting fixes the issue for me. Thanks again. |
Thanks for reporting the issue. We'll look into MySQL parser thing and see if we can provider something for Postgres SQL flavour |
I think we don't use them anymore, but they were working fine for a long time. The actual PostgreSQL syntax only uses two for type conversion ( The doubling was required by the context, I think to avoid ambiguity with named parameters' syntax which also use colons. |
Add validation logic to the language support for JPQL (etc.) wherever those languages are being used (annotations in Java source code, named query files, etc.).
The validation should report messages from the parser to the user in the form of diagnostics, as usual. The more detailed and fine-grained, the better - depending on that is possible using the parser at hand.
The text was updated successfully, but these errors were encountered: