Returns wrong BigInt insertIds

DB Schema

CREATE TABLE `users` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(20) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=12345678901234567945 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

MYSQL Config

  {
    host: 'localhost',
    user: 'develop',
    password: 'develop',
    database: 'develop',
    waitForConnections: true,
    namedPlaceholders: true,
    connectionLimit: 1,
    bigNumberStrings: true,
    supportBigNumbers: true,
  };

QUERY

INSERT INTO users(name) VALUES('test')

Response

[
  ResultSetHeader {
    fieldCount: 0,
    affectedRows: 1,
    insertId: '-6101065172474983670',
    info: '',
    serverStatus: 2,
    warningStatus: 0
  },
  undefined
]

Version: ^2.3.0

PS: Works as expected with https://github.com/mysqljs/mysql

[testn]

This was a MySQL bug 10 years ago https://bugs.mysql.com/bug.php?id=20964

[ruiquelhas]

Are you setting an initial AUTO_INCREMENT value when creating the table? Is it a BIGINT UNSIGNED column like the OP example?

That error should not be related to the fact that you insert a negative number. I think that only happens when the AUTO_INCREMENT value is already out of range for the given column data type.

For instance, using OP’s example but instead making the id column a BIGINT SIGNED (mind that by omission, numeric columns are SIGNED), it will fail with that same error because the initial AUTO_INCREMENT value is already out-of-range. So, if you rely on it whilst inserting anything and not providing a specific id value, it will yield that error.

CREATE TABLE test (id BIGINT AUTO_INCREMENT NOT NULL, name VARCHAR(25), PRIMARY KEY(id)) AUTO_INCREMENT=12345678901234567945;
INSERT INTO test (name) VALUES ('foo');
-- ERROR 1467 (HY000) at line 2: Failed to read auto-increment value from storage engine

The problem with your example is that, if the column data type is SIGNED, negative numbers are valid, so there’s no reason to not allow that.

Of course if the column data type is UNSIGNED then you already get an error if you try to INSERT negative values.

CREATE TABLE test (id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, name VARCHAR(25), PRIMARY KEY(id)) INSERT INTO test (id, name) VALUES (-10, 'foo');
-- ERROR 1264 (22003) at line 2: Out of range value for column 'id' at row 1

The only problem here is that insertId creates false expectations about what it returns. To make matters worse, LAST_INSERT_ID() also does not help. Both those values are only reliable if you don’t source your own values while INSERTing.

I’ve talked with a few people (working with client implementations) about it and some of them were not even aware of this kind of behaviour, which means it probably hasn’t been an issue. Maybe that’s because the behaviour is documented somewhere (couldn’t find anything).

So, the idea that I got was that we probably need to live with it. And to be honest, I don’t see any kind of limitation here as well. When your INSERT relies on values “generated” by AUTO_INCREMENT, the insertId is fine. When you provide your own values, you already know them, so there’s no point in looking for whatever is returned by insertId. It might be a bit more tricky for bulk inserts, but the reasoning still stands.