- Correct. - Incorrect. They are all inside a single LMDB file. So there is not an open file handle for every actor. > How do you coordinate safe schema chang

- Correct. - Incorrect. They are all inside a single LMDB file. So there is not an open file handle for every actor. > How do you coordinate safe schema changes across all actors? Before committing a schema change, we test it against the existing schema. If SQLite runs the SQLs successfully (on a dummy memory-only database) it is committed. We do not guard against writing updates which might succeed in some actors and not succeed and others. It is the developers/administrators responsibility to create schema updates that are valid. We assume schema changes are reasonable (add tables, columns, indexes). Not rewrite the entire schema kind. Of course you can do that, but it's your responsibility that it is working. If there is any doubt of a schema update, one can always create a dump of the live database, start it up in a staging environment and perform the planned update there first. > But for many types of schema changes you do want a controlled migration where you ensure that all tables are fully updated. Can you force the schema upgrade by touching all agents with a dummy query, perhaps? I don't really see a benefit in doing that. But you can very easily write such a query: "actor mytype(*); select id from sometable limit 1;" > Thread example... The user actor would be the right place to store the list of threads where it has commented. So every post would be a transaction to thread (where the message and actor id would go) and user actor (that would just store a list of thread ids). There is also another way of modelling a forum that I think would be better. Have two KV types, users and threads. The schema: ------------ actor user kv CREATE TABLE actors (id INTEGER PRIMARY KEY, hash INTEGER, name TEXT); CREATE TABLE messages (user INTEGER, thread INTEGER, FOREIGN KEY (user) REFERENCES actors (id) ON DELETE CASCADE, PRIMARY KEY (uid,thread)) WITHOUT ROWID; actor thread kv CREATE TABLE actors (id INTEGER PRIMARY KEY, hash INTEGER, title TEXT, date INTEGER); CREATE TABLE messages (id INTEGER PRIMARY KEY, thread INTEGER, uid INTEGER, txt TEXT, FOREIGN KEY (thread) REFERENCES actors (id) ON DELETE CASCADE); ------------ KV types with sub-tables are quite powerful. You can have a rich data model and the data will not be too fragmented over a large number of actors. > How much failover testing have you done on your Raft implementation? Replication receives the bulk of testing.