Mismatch of postgres int type of field eventid in events and field last_value in eventsnxtid
Description
In postgres db, there's a mismatch of int type between table events and eventsnxtid.
type int
type bigint
This leads to unexpected behavior when the eventid reaches the max value of the `int` type range and the eventsnxtid continues to count up. The adverse behavior can be the eventid wraps around from a positive integer max number 2147483647 to a negative integer min number -2147483648 and the subsequent negative numbers.
The deeper I get into this, the more code that needs changing. After talking with about it I'm gonna set this aside for now and maybe we can revisit it later.
It doesn't just require changing the database, it requires changing basically every bit of code that touches events in the OpenNMS codebase to use Long values rather than Integer values.
It is, honestly, probably less work to write a utility to "pack" (defrag? lol) events rather than trying to uplift the entire codebase to use 64-bit integers internally.
Considering how the fix needs to be implemented, I'm hesitant to do it in 2019 and 2020 since they're not supposed to get bigger fixes, so I've retargeted this to just 2021 and H29.
Benjamin Reed December 21, 2021 at 4:07 PM
Honestly we should probably audit all the places we're still using integers and see whether there's any reason not to bump it. But events is probably the most likely place to have issues.
In postgres db, there's a mismatch of int type between table events and eventsnxtid.
type int
type bigint
This leads to unexpected behavior when the eventid reaches the max value of the `int` type range and the eventsnxtid continues to count up. The adverse behavior can be the eventid wraps around from a positive integer max number 2147483647 to a negative integer min number -2147483648 and the subsequent negative numbers.