Skip to content
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

Report correct error for value lists in joins #156

Merged
merged 3 commits into from
Nov 20, 2024

Conversation

aseigo
Copy link
Contributor

@aseigo aseigo commented Nov 20, 2024

See #138

The wrong error was being thrown due to the third param in the source passed into create_name is only a binary when its a prefix, while other SQL syntax passes in other terms as the third parameter.

JOIN VALUES((...),(...)) AS clauses pass in a {values, index, number_of_values} tuple as the third parameter, for instance.

So this fix is in two parts: one fixes quote_table to account for this, the other introduces an assert_valid_join that validates joins, generating consistent, clear errors as needed.

Note: I did actually attempt to implement VALUES() joins .. however, while SQLITE does support the VALUES() syntax, it does not work meaningfully in joins, as it does not support column aliases on tables, meaning there is no way to name the columns in the values list (as Ecto provides for), and as such no way to use a values list as a join table. I did get the actual VALUES list to be accepted by sqlite's query parser, though ... but that turned out to be for not due to these other limitations in the engine. Ah well ...

in the case of `create_name`, then third param may be a string or atom
prefix ... and in those cases should be treated as a prefix.

however syntax such as `VALUES (...)` will pass in the values list
information as the third tuple. this was causing spurious exceptions
to be thrown, rather than creating the correct table name
This improves the error messages for `JOIN VALUES (...) AS` clauses
which were being mistakenly tagged as a table prefixing issue. Now the
user gets a more accurate message.

It also puts all the join syntax checking into a single function which
makes it a bit eaiser to reason about (e.g. that hints, values, etc. are
not OK, but other join constructs are)
@warmwaffles
Copy link
Member

There may be value in supporting VALUES() for a completeness sake so that queries can be built on the fly and the developer wants to issue it. Sort of like a where true = false clause.

@warmwaffles warmwaffles merged commit b81cd48 into elixir-sqlite:main Nov 20, 2024
13 checks passed
@aseigo
Copy link
Contributor Author

aseigo commented Nov 20, 2024

If there is interest in supporting VALUES lists in general queries, I could whack that in for completeness .. though I would still reject them in JOIN statements, as they won't / can't work the way Ecto supports that construct. Let me know :)

@warmwaffles
Copy link
Member

The juice may not be worth the squeeze at the moment. Let's put a pin in it.

I released this fix under v0.17.5.

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

Successfully merging this pull request may close these issues.

2 participants