21–30 of 43 posts
Although the advantages are real, I can't say I have had much opportunity to implement schemas like this. The extra complexity is usually what gets in the way, and it can add difficulty to migrations.
I think it would be useful in certain scenarios, for specific parts of an application. Usually where the history is relevant to the user. I think using it more generally could be helped by some theoretical tooling for common patterns and data migrations.
It’s a mistake to use timestamp for sorting versions instead of revision_id imo
What case would you make for using revision_id?
This is relatively rare though.
[flagged]
[flagged]
"Do people really feel like languages and systems that enforce immutability help them? I'd be interested in any arguments for handling immutability with language restrictions over code guidelines, because I'm not seeing how we need these restrictions on a language level to get the benefits we want."
The above has a clear stance and still encourages conversation, I think. For what it's worth, I mostly agree with you that in the end, I don't really give a shit if we can mutate things. In fact, I think the places where our software falls apart the most (performance on different axes) would benefit from being able to mutate things for sure.
Author here, 8 years on. Although the advantages are real, I can't say I have had much opportunity to implement schemas like this. The extra complexity is usually what gets in the way, and it can add difficulty to migrations. I think it would be useful in certain scenarios, for specific parts of an application. Usually where the history is relevant to the user. I think using it more generally could be helped by some…
We also have help from other quarters nowadays.
Databases often provide a time travel feature where we can query AS OF a certain date.
Some people went down the whole event sourcing / CQRS / Kafka route where there is an immutable audit log of updates.
Data warehousing has moved on such that we can implement “slowly changing data” there.
All in all, complicating our application logic, migrations and GDPR in order to maintain history in line of business applications might not be worthwhile.
[flagged]
[flagged]
Earlier quoted context omitted.
Slightly unrelated: A great way to solve this specific email issue is to store hashes for emails only, similarly to passwords. When a user needs a password reset, they should send an email to a specific address, the sender mail is hashed, and if it matches a user, a password reset link is replied. That way a data breach can’t expose user emails. (This is what Tildes use: https://tildes.net/settings/account_recovery ,…
This works great for password resets. It does not work if you actually want to send emails, for instance notifications.
From a user's perspective, I can see a privacy drawback as well. Suppose that instead of a typical User table, you have a User_Revision table like suggested. Every time a user updates their account settings, you INSERT a new row there. If a user changes their email address, you get a row each time they update it. Not only the company gets an history of email addresses, but also they are tied to each other. If this in…
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.
[flagged]
[flagged]
This gives you the worst of both worlds. It requires programmer discipline, and it prevents non-obscure and relevant languages from reaping any of the benefits of immutability.
It’s a mistake to use timestamp for sorting versions instead of revision_id imo
What case would you make for using revision_id?
Earlier quoted context omitted.
It's ironic that postgres the underlying storage model for postgres are immutable tables that marks records as "invisible" and asynchronously cleaned up.
Yeah. Immutable design is better, what more is there to say? Unfortunately Postgres doesn't have an API to get at those well designed internals. It implements SQL.