-
Notifications
You must be signed in to change notification settings - Fork 50
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
"Illegal SQL CRUD operation(s) found in SQL" error #447
Comments
Hi @ndobb Hope you had a great vacation. Arthur |
Hi @artgoldberg, Ah - I think this is the culprit The token "with " is included in the illegal commands Leaf checks for https://github.com/uwrit/leaf/blob/master/src/server/Model/Compiler/Common/Dialect.cs#L76. Essentially this is just a crude case-insensitive check for any of the listed strings which could potentially refer to DDL operations (though I'm pretty sure One workaround could be to run something to replace the word "with" with something else, such as: UPDATE [app].[Concept]
SET SqlSetWhere = REPLACE(SqlSetWhere, 'with ', 'w/ ')
WHERE SqlSetWhere LIKE '%WITH %' In the future we could (1) write a proper parser, (2) remove Best, |
…s in 'concept' mappings in 'concept_relationship' o stop incorporating condition description in query, to avoid uwrit/leaf#447 bug o update todos
In the meantime, I'm not including documentation comments in Leaf queries. |
Thanks @artgoldberg. I've just released v3.10 (https://github.com/uwrit/leaf/releases/tag/v3.10.0), which removes "WITH" from the list of illegal commands. |
@ndobb In my opinion, this issue should be left open. Fundamentally, what's happening is that Leaf wants to ensure that dynamic queries do not execute DDL, and does so by raising the "Illegal SQL ... " error if they contain any DDL keywords. But this ignores the possibility that these keywords are in comments, or in literals used by queries, or in other SQL constructs. To summarize, while it's important to prevent dynamic SQL from damaging the database, this approach risks data-dependant false errors that are difficult to debug especially for users who have no contact with Leaf's developers, and leaves them in the cumbersome position of being unable to do reasonable things because Leaf raises a false error. In my view, an effective and non-risky approach to protecting the DBMS should be used instead. E.g., perhaps access protections could be used:
Regards, Arthur |
Hi Folks
A couple of our queries generate this error. Here's an example:
A log with 3 such errors and multiple lines before and after the error is attached.
filtered_leaf-api-20210914.log The error is in leaf/src/server/Model/Compiler/SqlValidator.cs. But I don't understand what it means.
These queries run fine as stand-alone SQL.
An unusual aspect of these queries is that the ICD10CM concept maps to multiple SNOMED concepts. (About 30% of the ICD10CM concepts in Athena map to multiple SNOMED concepts in the CONCEPT_RELATIONSHIP table.)
I suspect that this factor contributes to this error. In particular, the 1-to-many ICD10CM to SNOMED mapping means that a given condition_occurrence_deid record may satisfy the query multiple times, which could select duplicate person_ids. Maybe it needs to be wrapped in DISTINCT().
Thanks
A
The text was updated successfully, but these errors were encountered: