koskimas

PostsComments

KKysely

•Created by tzezar on 3/6/2025 in #help

Inconsistent Typing of NUMERIC Fields with jsonBuildObject

So, you either need those explicit casts, or allow the DB to cast the value to JSON number and fix your types.

10 replies

KKysely

•Created by tzezar on 3/6/2025 in #help

Inconsistent Typing of NUMERIC Fields with jsonBuildObject

The database + the driver are responsible for data types and conversions. Kysely never touches the output. On type level, we also don't know your string type is numeric and will get turned into a number by the database JSON functions.

10 replies

KKysely

•Created by tzezar on 3/6/2025 in #help

Inconsistent Typing of NUMERIC Fields with jsonBuildObject

There's no way for kysely to know which columns will get converted to what. Kysely has no runtime column type information whatsoever.

10 replies

KKysely

•Created by OverHash on 3/6/2025 in #help

AggregateFunctionBuilder inside a SUM

This also works if you really want to use the literal there https://kyse.link/mSLWJ

8 replies

KKysely

•Created by OverHash on 3/6/2025 in #help

AggregateFunctionBuilder inside a SUM

But you can just swap the multiplication around and there's no need to use eb.lit https://kyse.link/pnjEU

8 replies

KKysely

•Created by OverHash on 3/6/2025 in #help

AggregateFunctionBuilder inside a SUM

Here you go https://kyse.link/X1Vxc Our types are a bit too strict and give the type 100 instead of number for eb.lit(100)

8 replies

KKysely

•Created by OverHash on 3/6/2025 in #help

sql literal string in binary expression builder

You definitely don't want "1.0" since that means you're referencing a column named 1.0

9 replies

KKysely

•Created by OverHash on 3/6/2025 in #help

sql literal string in binary expression builder

https://kyse.link/MY40g

9 replies

KKysely

•Created by OverHash on 3/6/2025 in #help

sql literal string in binary expression builder

sql.lit(1.0) or eb.lit(1.0)

9 replies

KKysely

•Created by tzezar on 3/5/2025 in #help

Query result type mismatch

I implemented selectAll that way because I think some dialects actually select the parent columns as well if you use *. But I might've been wrong about that and it's actually just implemented wrong. But It's better to use table.* than * anyway. It's more specific and often makes the query easier to read.

7 replies