Maybe someday automerge’s serialization format will be as durable and universal as SQLite’s, but in the meantime, it’s certainly not amenable to casual concurrent local access in some user script.
Conversation
Of course, SQLite leaves you to solve syncing. The typical approach is a write-only log of events (CRDT mutations or otherwise) which can be replayed across replicas. Snapshots of entity states are computed from queries across these events.
1
17
That’s the approach Orbit takes: simple event structures (simpler than CRDTs, sacrificing some of their key guarantees to reduce complexity), with well-defined merge operations, in a SQLite db. Users can write scripts to insert their own events if they like.
2
1
24
I’m still not satisfied with this. Reading/writing data yourself requires using Orbit’s libraries or a SQLite library and an understanding of the schema. I’d like to just expose the data as plaintext, but I’m not yet sure how to achieve that practically.
3
21
(part of me thinks that maybe we /should/ all just get really fluent with SQLite & set a cultural expectation that everyone is as comfortable with that as they are with plaintext today)
2
1
8
I think that a good part of the cultural obsession with plaintext comes from decades of bad SQL tools. A SQLite database and an embedded schema *should* be better than a blob of JSON, but somehow it often isn't.
1
1
2
Right. There still isn't a SQL editor for Mac that I'd actually enjoy using for some extended creative work. Compare that to, say, text editors, which get lavishly appointed…
3
2
What kind of features would your ideal SQL editor include?
1
I'm not sure—understanding that would require some meaningful creative work, I think. But on the margin, the main thing that comes to mind is that I want something crafted, lovely, as well-formed to my hands as my text editor is.
1
4
Which text editor do you use?
1
Part of what's so interesting here is that it depends. Sometimes Sublime Text; sometimes vim; sometimes Bear; etc.