3 ms·

Hard to believe that all their customers had written their code to work with signed IDs though. Honestly I would expect that to break more users code (and in w

Hard to believe that all their customers had written their code to work with signed IDs though. Honestly I would expect that to break more users code (and in weirder ways) than just changing the type. It's unclear from the story how the type was exposed though.

crazygringo 1y ago
Came here to say exactly this. Programming languages usually default to signed, but if you're storing these things in databases it's common to explicitly choose unsigned, since ID's are virtually always unsigned and it gives you twice the space until you run out. Like, instead of using negative primary keys, they could have also just have converted to an unsigned int32. I would assume both of those would break a bunch of customer implementations though.
- sgarland 1y ago
  Postgres doesn’t have unsigned column types out of the box. There’s an extension that enables it, but you’d have to know about that (which you should, if you’re managing a DB, but I digress). MySQL does have unsigned ints out of the box, FWIW.
- NetMageSCW 1y ago
  One of them would presumably break every customer if the API was properly documented.
gcanyon 1y ago
Yeah, this was my immediate thought as well, but if the spec for the API says signed int, then at least you're defensible: you haven't broken the letter of the spec, even if you're pounding on the spirit of the spec pretty hard. You have a fairly reasonable likelihood that most/all of your customers have implemented to your spec, and therefore any negative consequences are down to secondary effects of how they handle the negative values, not directly because of failure to be able to store them. That said, to your point, there was almost certainly someone comparing IDs to determine recency, and during the transition from large-positive to large-negative, that would absolutely cause havoc. I'd be curious if their API spec actually said anywhere that the IDs increased consistently.
hn92726819 1y ago
I'd believe it. Not sure when this is, but if it's a few years old and business software, they could probably asume everyone uses java, which doesn't even have unsigned integers.
- swsieber 1y ago
  With $MY_JOB in java, that was my assumption
- IshKebab 1y ago
  Right but just because it's `int id` doesn't mean all code that uses it will still work when it's negative.
  - hn92726819 1y ago
    True, but it does seem like the best alternative here. If it's a SOAP API in 2005 for business customers, for example, then it sounds like the least bad option of the four (tell consumers to update, hold up the whole company's deployment, push negative ints, or push longs). I'm just saying that to me, it isn't hard to believe this was the best option here.

crazygringo 1y ago

Came here to say exactly this. Programming languages usually default to signed, but if you're storing these things in databases it's common to explicitly choose unsigned, since ID's are virtually always unsigned and it gives you twice the space until you run out. Like, instead of using negative primary keys, they could have also just have converted to an unsigned int32. I would assume both of those would break a bunch of customer implementations though.

sgarland 1y ago
Postgres doesn’t have unsigned column types out of the box. There’s an extension that enables it, but you’d have to know about that (which you should, if you’re managing a DB, but I digress). MySQL does have unsigned ints out of the box, FWIW.
NetMageSCW 1y ago
One of them would presumably break every customer if the API was properly documented.

gcanyon 1y ago

Yeah, this was my immediate thought as well, but if the spec for the API says signed int, then at least you're defensible: you haven't broken the letter of the spec, even if you're pounding on the spirit of the spec pretty hard. You have a fairly reasonable likelihood that most/all of your customers have implemented to your spec, and therefore any negative consequences are down to secondary effects of how they handle the negative values, not directly because of failure to be able to store them. That said, to your point, there was almost certainly someone comparing IDs to determine recency, and during the transition from large-positive to large-negative, that would absolutely cause havoc. I'd be curious if their API spec actually said anywhere that the IDs increased consistently.

hn92726819 1y ago

I'd believe it. Not sure when this is, but if it's a few years old and business software, they could probably asume everyone uses java, which doesn't even have unsigned integers.

swsieber 1y ago
With $MY_JOB in java, that was my assumption
IshKebab 1y ago
Right but just because it's `int id` doesn't mean all code that uses it will still work when it's negative.
- hn92726819 1y ago
  True, but it does seem like the best alternative here. If it's a SOAP API in 2005 for business customers, for example, then it sounds like the least bad option of the four (tell consumers to update, hold up the whole company's deployment, push negative ints, or push longs). I'm just saying that to me, it isn't hard to believe this was the best option here.