CRUD Actions: Modifying and Deleting Data

Holochain allows agents to ‘mutate’ immutable data by publishing special delete and update actions to the DHT.

What you’ll learn

  1. Why you can’t delete or modify DHT data
  2. How to simulate mutability in an immutable database
  3. Addressing concerns about privacy and storage requirements

Why it matters

Immutable public data is a surprising feature of Holochain and many other distributed systems. It’s important to understand the consequences in order to make informed design decisions that respect your users’ privacy and storage space.

Public, immutable databases

Data in a Holochain app is immutable for a couple reasons:

However, developers expect CRUD (create, read, update, delete) to be a basic feature of a database; it’s an important part of most apps. So how do we do it on Holochain?

Simulating mutability

You might remember from a few pages back that we described each record as an ‘action’, not a thing. When you create, update, or delete a piece of data, you’re actually recording the act of doing it. (This is called event sourcing, if you’re interested.)

Here are all the mutation actions an agent can perform:

In almost every case where an action ‘modifies’ old data, it’s simply sending a piece of metadata to be attached to the old data. The old data still exists; it just has a different status.

All the DHT does is accumulate all these actions and present them to the application. This gives you some versatility in deciding how to manage conflicting contributions from many agents, such as diverging updates on one text document.

It’s also important to note that an update or delete action doesn’t operate on entries or links — it operates on the actions that called them into existence. That means you have to specify an action hash, not just an entry hash. In the case of deletes, an entry or link isn’t dead until all the actions that created it are also dead.

This prevents clashes between attempts to delete identical entries written by different authors at different times, such as Alice and Bob both writing the message “hello”. That entry exists in one place in the DHT, but it will have two new-entry actions attached to it, each of which can be updated or deleted independently.

Resolving conflicts in a conflict-free database

You may be thinking, if an entry can accumulate multiple update and delete actions, which is the right entry? The answer is that it’s up to your application to decide. You may want to preserve all revisions and show them as a tree, allowing people to follow whichever path they prefer. You may want to write a simple conflict-resolution mechanism into your getter functions, such as “the earliest one wins” or “deletes always override updates”. Or you may want to incorporate automatic merge functions that apply all updates to the thing being updated, such as a conflict-free replicated data type (CRDT_.

You’ll also want to decide whether the primary units of data in your DHT are entries or actions (that is, entry plus author plus timestamp). There are appropriate places to use each, but that’s beyond the reach of this introduction.

In the future, Holochain may allow you to define CRDT-like automatic conflict-resolution strategies that collapse multiple CRUD actions into a consistent, canonical view of a piece of DHT data.

Handling privacy concerns and storage constraints

You’ve seen how deletes and updates don’t actually remove data; they just add a piece of metadata that changes its status. This can go against users’ expectations. When you ask a central service to delete information you’d rather people not know, you’re trusting the service to wipe it out completely — or at least stop displaying it. When your data is shared publicly, however, you can’t control what other people do with it.

In a sense, this is true of anything you put on the internet. Even when a central database permanently deletes information, it can live on in caches, backups, screenshots, public archives, reading-list apps, and people’s memories. Privacy is all about applying friction to data sharing, so your responsibility as a designer is to create appropriate levels of friction. Here are some guidelines:

Additionally, because data takes up space even when it’s no longer live, be judicious about what you commit to a source chain and/or DHT.

Finally, data that’s invalid (we’ll learn about that in the next section) can be removed by a DHT node that’s elected to validate and store it. And in the future Holochain will permit nodes to ‘purge’ the data they’re storing, for reasons other than invalidity, such as in response to right-to-be-forgotten requests, or flagging of immoral content, or simply because the data takes up too much space.

Key takeaways

Learn more

Next Up

Explore validation →

It looks like you are using Internet Explorer. While the basic content is available, this is no longer a supported browser by the manufacturer, and no attention is being given to having IE work well here.