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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

"IN" on empty array causes invalid SQL #709

Closed
eran-pinhas opened this issue Sep 20, 2023 · 11 comments
Closed

"IN" on empty array causes invalid SQL #709

eran-pinhas opened this issue Sep 20, 2023 · 11 comments
Labels
api Related to library's API duplicate This issue or pull request already exists enhancement New feature or request wontfix This will not be worked on

Comments

@eran-pinhas
Copy link

Not sure if it's by design or a bug but...

Trying to run db.selectFrom('person').selectAll().where('id', 'in', []) causes an invalid SQL (see image below馃憞 the () part is invalid).

Now obviously, this query doesn't make a lot of sense, and you can simply assume there would be 0 rows returned, but IMO ot. makes sense when in the TypeScript context, and also SQL generating library that creates an invalid SQL is a bit weird. The ways I think we can overcome this "issue" really depends on the philosophy Kysely is based on:

  • Leave it as is (Although I would suggest updating the docs to explain this non-trivial case)
  • Throwing a runtime error
  • replacing it with some sort of false statement (like IN (null) which should be equivalent)

Let me know what you guys think...

image

@koskimas
Copy link
Member

koskimas commented Sep 20, 2023

It is invalid SQL. Kysely builds exactly what you ask it to build. We never add anything unexpected to the SQL.

@eran-pinhas
Copy link
Author

eran-pinhas commented Sep 20, 2023

I know, that's what I'm saying. But don't you think a library for SQL generation should create only valid SQLs?

I do agree that the third option (the (null) one) is a bit interventive. but what about the first and second solutions?

  • Updating the docs to explain this non-trivial case
  • Throwing a runtime error

@eran-pinhas
Copy link
Author

@koskimas

@koskimas
Copy link
Member

koskimas commented Sep 20, 2023

Kysely should build what you ask it to build. You already get a runtime error. Feel free to create a PR that documents this 馃憤

@koskimas koskimas added duplicate This issue or pull request already exists wontfix This will not be worked on api Related to library's API labels Sep 20, 2023
@eran-pinhas
Copy link
Author

I'm sorry fella but with your tone I really don't feel like it. Good luck

@koskimas

@koskimas
Copy link
Member

koskimas commented Sep 20, 2023

You're asking me to build something for you for free after you're already using something I built for you for free. I don't care if you don't create the PR, but if you want it you need to write it.

@igalklebanov
Copy link
Member

Just wanted to jump in and say there was nothing wrong with @koskimas' tone here. 鉂わ笍

@igalklebanov igalklebanov added the enhancement New feature or request label Sep 22, 2023
@alessiocancian
Copy link

It is invalid SQL. Kysely builds exactly what you ask it to build. We never add anything unexpected to the SQL.

typeorm/typeorm#2195 (comment)

This is handled by the majority of ORMs and even query builders, so not handling it might be more unexpected...

@igalklebanov
Copy link
Member

Kysely differs in design philosophy from other libraries out there.

No magic. Explicit. Unopinionated. WYSIWYG (what you see is what you get).

It is what it is.

@koskimas maybe we could offer a plugin that adds a null literal to these lists?

@spinda
Copy link

spinda commented May 6, 2024

It does seem surprising that the code type-checks but leads to the generation of invalid SQL. Kysely uses the type system to protect you from accidentally generating invalid SQL in other ways. However, there doesn't seem to be a way to (ergonomically) express a "non-empty array" type in TypeScript.

@lithdew
Copy link

lithdew commented May 21, 2024

@spinda [unknown, 鈥nknown[]] represents a non-empty tuple type - casting to it needs to be done carefully though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Related to library's API duplicate This issue or pull request already exists enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

6 participants