How will version control (git) work with the DB version? I rely on git for incremental backup and tracking changes. This is trivially easy to do when working with clear text / markdown.
You already can if you know how to do it, the branch on GitHub is feat/db
.
I want to know if the page in the database version can be easily converted into PDF for sharing、printing. The export effect of the current plug -in is average and there is a linked jump failure.
When Logseq implements database as a way of storing the data, does that mean that file will no longer be in plaintext? I’m asking this mostly for GIt syncing.
Will there be a truly Portable version along the other installers? We need not install Logseq on all the devices we touch for privacy reasons. Also I don’t want any data to be left on a device where I start Logseq to note down journal entries along PKM and Task Management entries …
I never worked with databases except doing simple queries, and was wondering how is data stored in a file system? I guess it’s not one file representing one page. Where can I learn more about this, i.e. database and how is data stored on a filesystem.
SQLite uses a single file while PostgreSQL for example multiple files. I think Logseq will just use a single file.
Hi,
Do you think the database version will facilitate the migration from Roam Research?
I am asking because the migration process is taking me much more effort than I originally thought. This is due to two main issues:
- File name limitations on multiple platforms: I use MacOS, Android and IpadOS, meaning that I have to rename many of my pages to store them on all devices.
- I’m also extensively using nested page titles that are badly managed in Logseq.
I have the intuition that the database version could directly solve the first issue and maybe help with the second one. But if not, I’m interesting to know to avoid waiting in vain
Since many people seems to also consider migrating, this could be useful information in general.
Thank you
When are we getting the replies for these?
I won’t be replying to the questions directly; the questions are input for a blog post I’m writing. You can find the outline of the questions I’ll tackle first in the OP of this thread.
What’s the internal schema design (page, block, property, link etc.) in DB version? I’ve worked with graph database and think it valuable to support more popular graph databases as a backend, or at least a exporting target
Will there be a way to write to the DB version from other apps? Currently I have scripts which write changes to the underlying md files to get information into LogSeq.
I’ve deleted the last two messages. @tjstankus and @Bryn_M: please use the DM functionality to chat. This thread is for questions only.
Sorry to be strict, but otherwise this thread will be impossible to work with if I have to weed out the questions from the discussions.
Related question: if I’m already using a lot of properties, how will the migration work when switching to the DB version?
If Postgres is used (faster, reliable), how will you manage the postgres versioning update process that requires user intervention? (at least on linux)
They use SQLite like most local apps that need a database because SQLite is the most reliable persistent storage you can have on PCs. PostgreSQL is a totally different beast and it is used when you have many different users of the database, so on servers. And the user intervention you are thinking about is the one by sysadmins on servers, not Linux users on PCs.
Any updates on when the database version will be released for beta or regular use?