So, if you still have questions about the upcoming database version, please reply to this post and I’ll work with the developers to give as precise and in-depth answer possible.
How should we prepare our graphs for the DB version? I know there is a conversion? but is there anything that we need to do on our end to make the conversion go smoothly?
I have a lot of questions , the Markdown Bi-Directionality Issue still being at the top but I am also interested about a local LLM integration. It would have been quite trivital to have a local LLM read markdown files but for an LLM to read a binary database? I was seeing as imperative to achieve some local LLM integration with Logseq but now I don’t know what is the Logseq Team’s plan for closing the gap with other similar apps on the AI front?
Is the markdown version of Logseq still treated as a first-class citizen in the Logseq ecosystem?
In other words, do features introduced in the database version of Logseq get implemented in the markdown version as well?
If the team focuses on developing the database version of Logseq, how can existing users who prefer the markdown version benefit from the progress and new developments in Logseq ?
In connection to questions regarding the DB ↔ markdown sync:
the new handling of properties seem to be tied with the db version. visually, properties are shown as child bullets. will the markdown representation of properties in the DB version stay the same as they are now?
tasks / todos have become tag-based in the current db version using #Task. will the regular TODO checkbox disappear in the future? i feel like the ease of use of the current TODO UX is better than the tag-based todo that relies on tags, properties and dropdowns. add to that that it’s already hacky to create a checkbox that’s not a todo, and now we’re adding more complexity to create a todo. hopefully the tag-based todo becomes optional.
Will DB version improve multi-window mode too? I guess yes.
Will the bi-directional sync with MD files be available (optionally) with the Web version too? It would make Logseq 100% local-first even when you can’t install anything natively.
Will the bi-directional sync with MD files be available on mobile platforms too?
Will the bi-directional sync write to MD files also the schema for the new properties templates (like types, cardinality etc)? It would help a lot with refactoring.
Do you have any plan to support other formats for bidirectional sync, like CSV for tables and query results or YAML for the schema mentioned above?
Will plugins be able to add custom properties to blocks that won’t appear in MD files? It would be useful for those plugins that perform sync with other services like Todoist without polluting MD files with “meta” properties.
Could there be an option to resolve queries results when writing to MD files? I mean query results being readable in MD files and if you edit them manually with a text editor the original block is updated.
I’ve built a really nifty and fairly robust system to two-way sync logseq tasks with Apple iOS Reminders via Shortcuts and iCloud (my logseq drive is hosted in icloud for this purpose). Will we be able to ask Logseq to use the database for 90% of content, but mark a few topics / files as MD only so automations like my system can continue to work?
PS happy to share my Shortcuts setup if there is interest … it took a while to get working robustly!
Looks like the web version will be powerful. Super excited to get my hands on it.
Will we be able to self-host it? I mean will we be able to host that sqlite database on the server alongwith the app? (to ensure smooth sync for free users?)
That’s an absolute important question- for me, having .md files is one major requirement, I don‘t want/ need a DB version, is it still being maintained?
Currently a query result is just a static output of the relevant content.
With the db version, will it be possible to edit the actual values, directly within a query result in table view?
For example, say I have hundreds of blocks representing books, each with a property for author. Then I do a live query showing all these books in a table, including a column for author. Then I would be able to change the authors names directly in that table (as in a spreadsheet software).
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.
, the Markdown Bi-Directionality Issue still being at the top but I am also interested about a local LLM integration. It would have been quite trivital to have a local LLM read markdown files but for an LLM to read a binary database? I was seeing as imperative to achieve some local LLM integration with Logseq but now I don’t know what is the Logseq Team’s plan for closing the gap with other similar apps on the AI front?