-
Notifications
You must be signed in to change notification settings - Fork 7
Description
I noticed that bigint is treated as number in the output types, which is usually incorrect as bigint can contain a i64, while JS numbers can only contain integers below Number.MAX_SAFE_INTEGER (9007199254740991, which is below 52 bits).
Most DB libraries either default to mapping bigint to string or BigInt, or have options to do so. This library, however, maps them to number, which doesn't reflect what is expected input or output from those libraries.
Further, the DATE type is mapped to Date, despite Date representing a timestamp. This too is incorrect, as there's a clear difference between the symbolic date 2001-02-03 and the local instant 2001-02-03T00:00:00 [Localtime]; they might even be on different dates depending on the local timezone, and they might be mapped differently.
Would this project be open to allowing custom type mapping inside the config file? Perhaps like this:
I might be able to help out with this, if need be.
{ "connections": { "some_mysql_db": { "DB_TYPE": "mysql", "type_mapping": { "date": "string", // The `mysql2` library default to returning `number` for small // `bigints` and `string` for lagrge `bigints`. (Yes, really.) // sqlx-ts need to support union types. "bigint": "string | number", // If we configured our client to only return `string`, then we can // also enable that like normal: // "bigint": "string", } }, "some_pg": { "DB_TYPE": "postgres", "type_mapping": { // Date cannot work with arbitrary timezones, so let's imagine that // we've configured the `node-pg` library to parse `timestamptz` using // Luxon's `DateTime` instead of `Date`. // We need to be able to refer to types that have to be imported. "timestamptz": { "type": "DateTime", "import": "import type { DateTime } from \"luxon\"" } } } } }