Thank you for your answer @alex0, I learn a lot reading your comments. Wich are very objetive and clear to understand.
Logseq updates the file as soon as you unfocus a block, this makes Logseq write to files even more frequently than a text editor where you have to Ctrl+S to manually save.
Good to know.
OP was wrong about how Refresh and Reindex work and this made them think there is a “middle layer” or an additional step like Ctrl+S in text editors.
Technically, there is an intermediate layer, in any case, between leaving the editor and the “corresponding” file saved in the relevant storage.
Now, when Logseq is currently running interacts with the runtime environment via a runtime system. The runtime environment in turn acts as a go-between between the application and the operating system.
I see here an intermediate layer between the action of unfocusing a block (exiting the editor) and writing to the storage in order to achieve “persistence” of the database. In any case, I was referring more to the fact that Logseq uses a graph database and I was wondering what it could conceptually bring about when it is stored in a file system.
On the other hand, when you comment “what else Logseq could do? Write on the file every time you digit a character?” You say that like it’s silly, but it doesn’t sound so silly when you put it in the context of real-time collaboration, Etherpad Lite style, where instead asking to make write calls to the filesystem, the client submits a changeset to the server.
And if it makes sense in that context, given its centralized architecture and real-time requirement, I don’t see it unreasonable to wonder why something like this wouldn’t be possible in a local environment with multiple instances.
Finally, I think that when someone asks a question, the misunderstanding of something is usually implicit in the fact of asking.