Support tuples

[koskimas]

This PR adds tuple support. After trying out a bunch of options, I ended up with a function overload approach up to tuples of length five. There's also a partially unsafe $asTuple function in SelectQueryBuilder that I don't love.

The reason for my choices basically boils down to the fact that typescript doesn't allow the index of a type in an union to be observed. They've stated in some issues that it will never be observable.

Because of this, there's no (sane) conversion from an object to a tuple, which is why the $asTuple method is necessary. If you google this, there is a solution, but it takes around 3 gigabytes of memory to convert a single object to a tuple, so that's a hard no-no.

Using function overloads instead of a recursive type (like the one in coalesce) is also due to performance AND autocompletion issues. The recursive type immediately caused ~one second delays and I wasn't able to get autocompletion to work. Just like we don't currently have autocompletion in coalesce after the first argument.

Having a maximum length of five for tuples shouldn't be an issue. My guess is that the most common use case for this is composite primary keys and the length for those is usually 2 or 3. We can also add more overloads if someone requests them.

Closes #367

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
kysely	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 25, 2023 11:30am

[thelinuxlich]

Wouldn't refTuple be a better option, following the pattern of whereRef?

[koskimas]

Wouldn't refTuple be a better option, following the pattern of whereRef?

Yeah, but on the other hand, most functions take references by default. I don't know which is the better "default". @igalklebanov Thoughts?

[koskimas]

@thelinuxlich Did you mean we'd have refTuple and valTuple or refTuple and tuple?

[thelinuxlich]

refTuple and tuple

[thelinuxlich]

because val at least there is no precedent in the API, right?

[igalklebanov]

@koskimas @thelinuxlich
Sorry, I didn't go over the changes yet, but regarding the naming..
feels like it should be tuple(...literalsOrExpressions) and tupleRef(...refs).
it'll be mostly used with literals in where clauses, and this way it's aligned with other places in the API - consistency.

[igalklebanov]

@koskimas @thelinuxlich Sorry, I didn't go over the changes yet, but regarding the naming.. feels like it should be tuple(...literalsOrExpressions) and tupleRef(...refs). it'll be mostly used with literals in where clauses, and this way it's aligned with other places in the API - consistency.

Actually, when used in where, there's still going to be ref usage in the lhs. This is a tough one, but seems like consistency should rule here.

[koskimas]

I think it should be refTuple "reference tuple" instead of tupleRef "tuple reference". Tuple reference sounds like a reference to a tuple.

[koskimas]

Actually, when used in where, there's still going to be ref usage in the lhs. This is a tough one, but seems like consistency should rule here.

Yeah, for now pretty much the only use case for this is

eb(refTuple('first_name', 'last_name'), '=', tuple('Jennifer', 'Aniston'))

so I'd say refTuple will be used just as often as tuple.

[koskimas]

@igalklebanov @thelinuxlich I renamed the functions.

[igalklebanov]

Amazing stuff! 👨‍🎨

Left some comments..