Drizzle Team•2y ago

Weird number overflow behavior between two database types

So I've got two databases that I use when developing locally, one is a Planetscale database and the other is from a docker image mysql:8.0.31-oracle I'm transitioning from storing Discord snowflakes as varchars to bigints to make sorting faster and so I don't have to cast them, to do that I'm using the following custom type so I don't have to update everywhere in my codebase to use bigints yet:

const snowflake = customType<{
    data: string;
}>({
    dataType() {
        return 'bigint';
    },
    // @ts-ignore
    fromDriver(value: string) {
        return value.toString();
    },
});

const snowflake = customType<{
    data: string;
}>({
    dataType() {
        return 'bigint';
    },
    // @ts-ignore
    fromDriver(value: string) {
        return value.toString();
    },
});

What's interesting with this is when using the Planetscale database, it returns the value correctly, but when using the local MySQL database it is off by a bit Value written: 1154666902883410021 Planetscale returns: 1154666902883410021 Local MySQL returns: 1154666902883410000 which is what you get from doing Number(1154666902883410021) If I check the value that's in the local database also I see 1154666902883410021 so I'm not really sure what's happening with this

Solution:

I am dumb salute

For anyone else who runs into this problem, in your MySQL2 connection set supportBigNumbers: true ```ts...

Jump to solution

2 Replies

RhysOP•2y ago

Upon diving into the drizzle code a fair bit, I think this may be a MySQL2 issue not a Drizzle issue

Solution

Rhys•2y ago

I am dumb salute

For anyone else who runs into this problem, in your MySQL2 connection set supportBigNumbers: true

mysql.createPool({
        supportBigNumbers: true,
        uri: dbUrl,
    }),

mysql.createPool({
        supportBigNumbers: true,
        uri: dbUrl,
    }),

Gaming

Programming

Weird number overflow behavior between two database types

Did you find this page helpful?