3 ms·

Digging through the docs, I can't find any actual information of the consistency and isolation guarantees other than "consistent" and "ACID". That's an immedia

Digging through the docs, I can't find any actual information of the consistency and isolation guarantees other than "consistent" and "ACID". That's an immediate red flag for me. What are the actual isolation characteristics of the database? Does it use snapshot isolation? Is it serializable? Is it linerizable? With all the great work Kyle Kingsbury (aka Aphyr) has done on the Jepsen tests, it's pretty clear that claiming to be "ACID" with no additional info isn't sufficient for a modern database.

thelastidiot 8y ago
Most docs for technical projects are written that way these days. The author of an api, project or solution will assume an unquestioned adoption "because it's free" from the randome audience with no specifics on how they are solving and more importantly what's different from other cases. I don't know if this is by laziness and writing procrastination, but assuming that your users will know as much as you do on your journey to assemble a solution has become a frustration when I discover new projects like this one.
- RhodesianHunter 8y ago
  Likely has a lot more to do with the fact that the intersection between the population that can create such projects and the population that can write clear effective documentation is exceedingly small.
  - bonesss 8y ago
    I would also point to Paul Grahams insight around hackers and painters[0]: the population who wants to create such projects is fantasizing about coding, hacking, publishing, bug squashing, and launches. Documentation isn't necessarily pulling them to their PC after a heavy dinner. - [0] http://www.paulgraham.com/hp.html http://www.paulgraham.com/hp.html
- pests 8y ago
  I feel as if you have a bit of a tone against these authors. Would you rather the software not exist at all?
samatman 8y ago
SQLite uses serializable isolation by default, this is built on top of that. I'm also curious how Raft is used and what the resulting guarantees on distributed table operations are, but I'm coming at it assuming good faith, since SQLite is... robust.
- atombender 8y ago
  Explained in the docs [1]. They replaced the SQLite WAL with one that uses Raft. Each actor has its own WAL, and so I suppose only operations within a single actor are consistent. Multi-actor transactions use two-phase commits. [1] http://www.actordb.com/docs-howitworks.html http://www.actordb.com/docs-howitworks.html
- thanatos_dem 8y ago
  > SQLite uses serializable isolation by default, this is built on top of that. That's sort of a meaningless statement tho. Everything in the world is built on top of RAM which is serializable. The real complexity comes in how those foundational blocks are abstracted and combined. We know that it's not performant at scale to represent an entire database log a single Raft group. So how are the Raft groups structured organized, and how and when do they cross-communicate?
  - atombender 8y ago
    See the docs [1]. As I understand it, each actor is a Raft group. Each actor has its own independent SQLite WAL. [1] http://www.actordb.com/docs-howitworks.htmlhttp://www.actordb.com/docs-howitworks.html http://www.actordb.com/docs-howitworks.htmlhttp://www.actord...

thelastidiot 8y ago

Most docs for technical projects are written that way these days. The author of an api, project or solution will assume an unquestioned adoption "because it's free" from the randome audience with no specifics on how they are solving and more importantly what's different from other cases. I don't know if this is by laziness and writing procrastination, but assuming that your users will know as much as you do on your journey to assemble a solution has become a frustration when I discover new projects like this one.

RhodesianHunter 8y ago
Likely has a lot more to do with the fact that the intersection between the population that can create such projects and the population that can write clear effective documentation is exceedingly small.
- bonesss 8y ago
  I would also point to Paul Grahams insight around hackers and painters[0]: the population who wants to create such projects is fantasizing about coding, hacking, publishing, bug squashing, and launches. Documentation isn't necessarily pulling them to their PC after a heavy dinner. - [0] http://www.paulgraham.com/hp.html http://www.paulgraham.com/hp.html
pests 8y ago
I feel as if you have a bit of a tone against these authors. Would you rather the software not exist at all?

samatman 8y ago

SQLite uses serializable isolation by default, this is built on top of that. I'm also curious how Raft is used and what the resulting guarantees on distributed table operations are, but I'm coming at it assuming good faith, since SQLite is... robust.

atombender 8y ago
Explained in the docs [1]. They replaced the SQLite WAL with one that uses Raft. Each actor has its own WAL, and so I suppose only operations within a single actor are consistent. Multi-actor transactions use two-phase commits. [1] http://www.actordb.com/docs-howitworks.html http://www.actordb.com/docs-howitworks.html
thanatos_dem 8y ago
> SQLite uses serializable isolation by default, this is built on top of that. That's sort of a meaningless statement tho. Everything in the world is built on top of RAM which is serializable. The real complexity comes in how those foundational blocks are abstracted and combined. We know that it's not performant at scale to represent an entire database log a single Raft group. So how are the Raft groups structured organized, and how and when do they cross-communicate?
- atombender 8y ago
  See the docs [1]. As I understand it, each actor is a Raft group. Each actor has its own independent SQLite WAL. [1] http://www.actordb.com/docs-howitworks.htmlhttp://www.actordb.com/docs-howitworks.html http://www.actordb.com/docs-howitworks.htmlhttp://www.actord...