executeTakeFirstOrThrow includes the query node in the error by default

[woltsu]

Hello, and thanks for the amazing library! 👋

I noticed that when using the executeTakeFirstOrThrow, the resulting error will contain the query node by default if the query fails to find any results. In many cases that might not be a big issue, but for some applications that handle personally identifiable information, this can cause some problems.

Now, one can pass the errorConstructor to the function, but it can be a bit annoying and error-prone to copy-paste it in many places. Thus, I'm wondering if it would make sense to add the possibility to globally configure it somehow, so that the compiled query would not be logged by default? Or at least an option to filter out the nodes that contain the actual values.

[igalklebanov]

Hey 👋

Interesting. 🤔

@koskimas maybe:

eb.valSensitive(value)
eb.litSensitive(value)
sql.valSensitive(value)
sql.litSensitive(value)

or

eb.val(value, { sensitive: true })
eb.lit(value, { sensitive: true })
sql.val(value, { sensitive: true })
sql.lit(value, { sensitive:  true })

or

eb.val(value).sensitive()
eb.lit(value).sensitive()
sql.val(value).sensitive()
sq.lit(value).sensitive()

wdyt?

It's the same underlying nodes, just with some extra metadata. We could then transform the tree before throwing. Produce a redacted sql string on-demand.. etc.

[igalklebanov]

Not sure this is part of a query builder's responsibility.

What are you using for logging? Solutions in that space have ways to configure automatic redaction of specific keys or values.

I like the idea of passing an error function to Kysely constructor that replaces the basic one for all queries that are executeTakeFirstOrThrown.