Mnesia Vs Actor State

Run in Livebook

Index

  1. Toc
  2. Contributing
    1. Understanding Any Module
    2. Style Guide
    3. Writing Documents
    4. Examples Over Testing
    5. Git
    6. Iex
    7. Mnesia Vs Actor State
    8. Observer
    9. Testing
      1. Running Tests
      2. Writing Tests
  3. Visualization
    1. Actors
  4. Hoon
    1. Calling
    2. Dumping
    3. Setting Up
  5. Analysis

Where should state be stored

One interesting thing about our system is that in the user data section of our documentation we talk about how Anoma's state is stored in RocksDB tables on disc. And that we have some kind of dump format that goes along with the tables.

The dump format stores 2 kinds of information:

  1. Actor State
  2. Mnesia State

As discussed in the user data documentation, loading a dump file overwrites the DB. However what we did not cover is what the differences are between Mnesia storage and Actor storage.

Mnesia Storage

The philosophy for what is stored in Mnesia should be: "Is this something the user should be able to query and write code over". Since Anoma is a distributed operating system project, many of the answers should be yes. The user should be able to make full fledged progrmas on Anoma and extend the system.

Actor Storage

Actor storage on the other hand are for things we don't wish the user to be able to query. Thus implementaiton details about the execution should be omitted from user visible storage, and would be better served stored on the Actor.

A good example of this is the old ordering logic.

  typedstruct do
    field(:table, Router.Addr.t())
    field(:next_order, non_neg_integer(), default: 1)
    field(:hash_to_order, %{key() => non_neg_integer()}, default: %{})
    field(:logger, Router.Addr.t(), enforce: false)
  end

In this example, we store things like specific order information, the live router addresses for storage and for the logger. None of this is relevant to the users and are just coincidental with how we wrote the system.