3 ms·

What I've find most useful is the immutable nature of the database. That within a reactive framework for UX is great combination. You get really cool things to

What I've find most useful is the immutable nature of the database. That within a reactive framework for UX is great combination. You get really cool things to happen with little effort. Also, because the database is a value. You can easily do mock data and isolated transactions locally to experiment and test. This makes some things easier. Another cool thing is how you do cross database queries by simply passing multiple databases to a function. It will pull in the subset of the dataset needed to compute the query result. It's that easy to do. It's not good at dealing with high volume transactions (a lot of writes) it's not too bad but it's not built for that primarily.

amelius 4y ago
> What I've find most useful is the immutable nature of the database. Not really a good fit for today's world of privacy regulations, where deletion of data should be possible and guaranteed.
- lgas 4y ago
  Datomic addresses this via Excision. https://docs.datomic.com/on-prem/reference/excision.html https://docs.datomic.com/on-prem/reference/excision.html
- _rcil 4y ago
  XTDB has a simple `evict` operation to resolve precisely this issue: https://docs.xtdb.com/language-reference/datalog-transactions/#evict https://docs.xtdb.com/language-reference/datalog-transaction...
- john567 4y ago
  This can be solved in different ways. First, everything is an entity, so you can enrich attributes with information about how they should manage PII/SPI data. There's nothing built-in but you can build meta models easily. Second, if you really have stringent requirements you would encrypt the data that is to be protected and throw away the encryption keys when the data needs to be purged. Datomic does allow you to opt out of history so the keys would not be recoverable in that case. Or, you just excise the data, at which point the information will be purged from the database. It's not instant, index rebuilds and garbage collection need to take place before it's really gone. You're in control. The fact that you have history isn't a problem.

amelius 4y ago

> What I've find most useful is the immutable nature of the database. Not really a good fit for today's world of privacy regulations, where deletion of data should be possible and guaranteed.

lgas 4y ago
Datomic addresses this via Excision. https://docs.datomic.com/on-prem/reference/excision.html https://docs.datomic.com/on-prem/reference/excision.html
_rcil 4y ago
XTDB has a simple `evict` operation to resolve precisely this issue: https://docs.xtdb.com/language-reference/datalog-transactions/#evict https://docs.xtdb.com/language-reference/datalog-transaction...
john567 4y ago
This can be solved in different ways. First, everything is an entity, so you can enrich attributes with information about how they should manage PII/SPI data. There's nothing built-in but you can build meta models easily. Second, if you really have stringent requirements you would encrypt the data that is to be protected and throw away the encryption keys when the data needs to be purged. Datomic does allow you to opt out of history so the keys would not be recoverable in that case. Or, you just excise the data, at which point the information will be purged from the database. It's not instant, index rebuilds and garbage collection need to take place before it's really gone. You're in control. The fact that you have history isn't a problem.