Right now I don’t rely on exporting to Markdown but have made modifications so I can make the very Markdown files from the Graph to render properly in any Markdown Editor/Viewer so I hope that, with the DB version and the Import/Export to Markdown, to have the possibility to have nothing stripped off or to choose what I want stripped off.
For example there are Logseq-specific properties, most of which are not visible in the UI anyway and there are user-defined properties. I would like a fine granularity on what not to export to Markdown (like logbooks maybe or Colapsed or some other specific logseq properties, while some other such logseq properties I would like to be able to retain, like Block ID etc);
I’d argue that talking about Markdown editors being mainstream, and that losing data in one Markdown file is less bad than losing it in a database, is kind of turning the bug into a feature.
As we know, Markdown is just plain text with conveniently light formatting and without an exact definition, which is why there are so many slightly incompatible flavors – and no one cares too much, because it’s still just plain text. It’s all for convenience. If it gets "corrupted’, what does that even mean, given that (again) there’s no exact definition? As long as it’s human-legible many wouldn’t even notice until the data loss is catastrophic.
Now, the moment you try to use such an ill-defined format as a database… how could that ever work, without tightening its definition and adding resiliency features that break its lightness and convenience? Suddenly you can no longer edit it manually, and 99% of mainstream editors don’t understand it or break it when editing. It’s the worst of both worlds: inconvenient pseudo-Markdown with bad structure for DB usage.
And I’d argue that that is the scenario we are in right now: why can’t Logseq files be simply used with e.g. Obsidian without breaking features? Why the Sync problems? Why even local data loss problems?? So I guess the devs realized that this route was going nowhere and decided to make the jump.
In a bad case scenario where the user has Logseq running on 2 machines and writes in one and then right through the other, with multiple files the worst case scenario is data loss for that one file that was edited.
With Sqlite however, the database is a single file, so the data loss is way more dangerous, since it could involve corruption too (and as such, complete data loss).
I know little about DBs, and still can see that there’s a lot of assumptions in that paragraph that make 0 sense to me.
DBs have been dealing with storage problems for half a century. Markdown is a toy text format that was originally published just as a blog post. The idea of a Markdown-based DB-like thing is… just asking for silly trouble.
If it is not bidirectional, it will most likely also make most sync tools painful to use due to the increased number of conflicts. Since everything will be editing a single “file(database)”, I feel like there will a lot more conflict cases when using tools like Syncthing or Dropbox to sync the data.