Skip to content

Make query translation more restrictive #15

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

Open
JanJakes opened this issue Feb 12, 2025 · 0 comments
Open

Make query translation more restrictive #15

JanJakes opened this issue Feb 12, 2025 · 0 comments

Comments

@JanJakes
Copy link
Contributor

The current query translation approach is rather minimalist, handling some differences between MySQL and SQLite, while leaving other/unknown syntax to fall to default translation handling and relying on the SQL dialect similarities.

For better confidence and data safety, it would be better to implement a more "allowlist"-oriented driver that would be explicit about what syntaxes are supported, leaving the rest as "unsupported". This is needed especially for data-writing queries, less so for read-only queries, in the following order of importance:

  1. DDL queries — here it's very important to allow only what we support to keep the information schema consistent.
  2. Data-writing queries — it can be important in some cases where an incorrectly understood query would result in a wrong operation.
  3. Read-only queries — here, allowlist can be a convenience (bail out early) rather than a necessity.

The full MySQL grammar contains many nodes, variations, and nesting, and it's hard to handle every detail using an allowlist — for instance, a specific construct may be generally valid in an expression, but not in an expression in a subquery in a join, etc. That said, I think we can be very explicit at the higher level — explicitly stating which top-level statements we do support and which ones we don't, and which main subconstructs of these statements are supported or not (e.g., LIMIT clause in a DELETE query).

See: #1 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant