Hacker News Reader

Comment by zeograd | Hacker News Reader

I often see code relying on the increasing property of primary key (keeping track of processed vs unprocessed by the last processed pk only).

This wrap into negative domain would wreck havoc for sure.

View on HN

You generally can't rely on strict monotonicity of primary keys, since the order in which transactions commit isn't necessarily the order in which the ids were generated. But I have relied on primary keys being "monotonic enough" to sort output by creation time for display purposes.

I've worked on invoicing software where we had to introduce a public, always +1 counter to ensure there are no gaps between invoices. Not +2, not +5.

That way you couldn't make them disappear.

That mustn't be the primary key, though, but a serial that counts (and is unique) per-customer.

This was before the SaaS days.

On-prem, single company who issued invoices to customers.

When there was an audit the government could ask to see invoices in a certain range. If some of them were missing, what does that mean? Paid under the table?

My wife worked at a place where they did manual PDFs, but there they had a tool to change properties of a PDF to change the creation time / last editing time, for when 'modifications' were needed.

And this reminds me of the other post here where some people assume cash means shady. Definitely the case there.

In the days when you used custom printed forms that had a number printed on them by the printer - when you loaded a new box of paper into your printer you had to input the first form number into the system so they'd match.

If you opened boxes in "whatever" order you'd have invoice numbers that would run contiguous for 150 or so counts (the number of forms in the box), then skip to the next multiple of 150 to correspond to when the next (or previous!) box had been used.

Well, I'd imagine that before returning the value through their API they could just check that if the number is negative, then add 2^32 to it, which would make it look like an unsigned 32 bit integer.

In most languages that support differently sized integer types and/or unsigned integer types, you wouldn’t have to check, but can just apply the appropriate modulo or bit operation on all values.

But isn't that exactly what they were trying to not do as their problem was the api users and not their internal use?

It was definitely a problem with their database but I suppose it's possible that the customers were also expecting 32 bit signed ints.

Reply on news.ycombinator.com