Immutable Data (2015) • Hacker News Board

Re: Immutable Data (2015)

#41

Post by steve_adams_86 » Tue, Jun 27, 2023, 3:36 AM UTC

zambal wrote: post #17

steve_adams_86 wrote: post #6

Earlier quoted context omitted.

What case would you make for using revision_id?

I'm not OP, but I can at least give an argument against using a timestamp for sorting versions: for various reasons system time is not guaranteed to be monotonic, which can result in cases where newer versions would be sorted before older versions. See https://www.erlang.org/doc/apps/erts/time_correction.html#in... for more info. It's about time handling in the Erlang run-time system, but the issue it describes is un…

This is great, thank you. I’d never considered using time stamps like this before which is why I was curious, but I suppose now I can continue not using them slightly more confidently. What is programming really, but figuring out what not to do.

Re: Immutable Data (2015)

#42

Post by steve_adams_86 » Tue, Jun 27, 2023, 3:38 AM UTC

nine_k wrote: post #22

steve_adams_86 wrote: post #6

Earlier quoted context omitted.

What case would you make for using revision_id?

E.g. timestamps may (slightly) differ if the updates occur in different transactions, while the revision ID is likely passed around, and is easier to correlate. This is relatively rare though.

It does seem like it would be rare, but it’s a valid concern. You can arguably gain any insights that time stamps offer by including them as metadata or in an audit log, right?

I find date and time data so difficult to work with that I typically avoid using it for anything important unless absolutely necessary.

Re: Immutable Data (2015)

#43

Post by ludston » Tue, Jun 27, 2023, 1:25 PM UTC

goodbyesf wrote: post #32

ludston wrote: post #4

Earlier quoted context omitted.

GDPR and the right to having your personal data deleted certainly puts a bit of a stopper on using an immutable database for anything personally identifying.

Pretty much all databases are "immutable". The logs contain every transaction ever made and most institutions save their logs. Also, backups of data are stored on tape and likely shipped somewhere for safekeeping.

That's not immutability, that's "log shipping". And if an organisation doesn't have the capability to delete personal data from it's backups, and it operates in Europe, chances are that it's in violation of GDPR and could be subject to millions of Euro's in fines.