node-mysql2
node-mysql2 copied to clipboard
sidorares
Why is it that `result.insertId` can be number or string when calling `insert()`
The code and these tests: (number, string) make me think that result.insertId can be either a number or a string. If that is correct, what was the reasoning for doing that? It puts the burden on the caller to deal with both types.
If it is expected behavior, I think it would be nice to update the documentation to state that it could return a number or a string.
I have enabled both big number configs: {supportBigNumbers: true, bigNumberStrings: true}
I would expect it to follow same rules as other numbers - number if can fit 53 bit, string if bigNumberStrings and supportBigNumbers
ref #108
main reasoning is that mysql type accuracy can be such that it cannot fit into JS number.
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER
Just to clarify:
if it can fit in 53bit it will always be number, regardless if bigNumberStrings and supportBigNumbers are set.
If it can't fit in 53bit it will return string if bigNumberStrings and supportBigNumbers are set, and error if they are not set?
Thanks for the quick response!
Just saw your last comment. I get the accuracy limitation, my doubt is why not always return a string? That way the caller doesn't have to worry about it being a string or a number.
yes, I kind of agree with you, I prefer to treat insertId as non-numeric unique id. Right now thie behaviour is made to be consistent with normal rows result where most of the time one prefer to have numbers as numbers. If we decide to change insertId behaviour that would require major version bump
Doesn't the insertId behavior not follow the same rules? When the new row id is small, insertId gives me back a number, but when I select from that same row, the id comes back as a string. This is with bigNumberStrings and supportBigNumbers enabled. I would expect the id to be treated consistently, regardless of whether it came from an insert or select and consider this behavior to not be self-consistent.
@pbomb I'm pretty sure the intention was to have this consistent, reopening to check and fix if not
@dvisztempacct no movement, thank for bringing attention, would like to fix that
( any help to fix would be appreciated as well - in any form, even pr with failing test covering this behaviour )
