Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Immutable Data (2015)

kevinmahoney.co.uk

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Immutable Data (2015)

#31

Post by refset »

benjaminwootton wrote: post #24
kpmah wrote: post #21

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…

I agree this is more of an application level concern than a database thing. If you need to maintain a history for the user requirement then you will naturally land on a scheme like this. 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 au…

> Databases often provide a time travel feature where we can query AS OF a certain date.

This is a good overview of SQL:2011 temporal functionality support across the major players: https://illuminatedcomputing.com/posts/2019/08/sql2011-surve...

Re: Immutable Data (2015)

#32

Post by goodbyesf »

ludston wrote: post #4
pil0u wrote: post #3

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.

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.

Re: Immutable Data (2015)

#33

Post by wredue »

roenxi wrote: post #20
jerrygenser wrote: post #19

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.

>what more is there to say?

That it’s not better. Immutability is a tool, not a rule. Deploying immutability unanimously without regard for anything is a great way to create a terrible application.

Re: Immutable Data (2015)

#34

Post by c_crank »

mrkeen wrote: post #28
phrenicfraud wrote: post #7

Earlier quoted context omitted.

[flagged]

> I don't want things to change, I simply will not change them, not rely on obscure and irrelevant languages 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.

Most relevant and non obscure languages support a const feature of some kind.

Re: Immutable Data (2015)

#35

Post by mrkeen »

c_crank wrote: post #34
mrkeen wrote: post #28

Earlier quoted context omitted.

> I don't want things to change, I simply will not change them, not rely on obscure and irrelevant languages 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.

Most relevant and non obscure languages support a const feature of some kind.

It's too little.

There's no language I know of where slapping 'const/final' in front of a field or a function will free you of the burden of considering whether you can safely share it (with the exception of primitives).

If I have a final field of Set, I can't return it, because the caller can insert a new user.

Re: Immutable Data (2015)

#36

Post by c_crank »

mrkeen wrote: post #35
c_crank wrote: post #34

Earlier quoted context omitted.

Most relevant and non obscure languages support a const feature of some kind.

It's too little. There's no language I know of where slapping 'const/final' in front of a field or a function will free you of the burden of considering whether you can safely share it (with the exception of primitives). If I have a final field of Set , I can't return it, because the caller can insert a new user.

Speaking as someone working in the CRUD Java salt mines, I've never had an issue with sharing variables like this that allegedly makes imperative programming fundamentally broken and unproductive. Scoping and any basically functional program layout does 95% of the work for you.

Re: Immutable Data (2015)

#38

Post by lichtenberger »

kpmah wrote: post #21

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…

You can use Datomic for instance (mentioned already in your article IIRC!?) or SirixDB[1] on sich I'm working in my spare time.

The idea is an indexed append-only log-structure and to use a functional tree structure (sharing unchanged nodes between revisions) plus a novel algorithm to balance incremental and full dumps of database pages using a sliding window instead.

[1] https://sirix.io | https://github.com/sirixdb/sirix

Re: Immutable Data (2015)

#39

Post by roflyear »

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.

First, I don't consider that immutable. Second, that isn't true for all databases, often you have to set it up and turn it on, and think about what you're doing as there are considerations for storage and backups. Third, it isn't like you can just get the data back magically and without effort. It can be a problem to hunt through. It can be an enormous amount of data.

Re: Immutable Data (2015)

#40

Post by code_biologist »

refset wrote: post #31
benjaminwootton wrote: post #24

Earlier quoted context omitted.

I agree this is more of an application level concern than a database thing. If you need to maintain a history for the user requirement then you will naturally land on a scheme like this. 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 au…

> Databases often provide a time travel feature where we can query AS OF a certain date. This is a good overview of SQL:2011 temporal functionality support across the major players: https://illuminatedcomputing.com/posts/2019/08/sql2011-surve...

I'm curious if the author of that blog ever completed their work with temporal Postgres. I know about [1] but unfortunately work on hosted Postgres most often where the extension isn't an option.

[1] https://pgxn.org/dist/temporal_tables/

Post reply on HN