Even though the team has been clear that Logseq DB is still an alpha product and have discouraged people from trying to use it for anything important, as the app gets better and better more and more people are naturally going to try to use it. I expect that to increase even more after the desktop version is released. So, to forestall any problems, I wanted to make people aware of some of the issues you will encounter if you try to import your existing graph into Logseq DB:
Missing Import features
First, we can start with the internal TODO list for improving import from the Logseq team.
- Import assets as #Asset and pdf annotations as pdf Annotation
- Import org mode files
- Import text files e.g. *.txt or *.edn
- Import advanced command blocks that begin with #+BEGIN
- Query macros and related query filters that have changed
- Page and block embeds
To that I would add the following:
- Preserve repeat settings on scheduled and deadline
- The ability to maintain separate NOW/LATER and TODO/DOING workflows.
I’m pretty sure the’ll fix repeat scheduling on import, but I’m not clear if they have any plan to let people keep custom workflows. If, like me, you have a custom workflow you want to keep, you may need to do some batch find/replace operations on your MD files before import. (Here is how I did that.)
But on top of all of that, what I think will confuse most people is the change in how #tags are handled.
NewTags vs. Pages
Right now, in Logseq MD, #tags are treated exactly the same as [[pages]]: both are links to pages, just with different formatting.
In Logseq DB, #tags are something entirely new. So new that I will call them #newtags here to make the difference clear. On import you can choose to convert all #tags to #newtags, or convert them to [[pages]], or you can specify only some tags to be converted to #newtags. Which you choose may depend on your existing workflow.
But how can people decide if they don’t understand what #newtags do? Basically a #newtag is a way of creating a database collection with a set of custom properties for each item. They are like “supertags” in Tana, who have an excellent description here:
If you want to test it out, try this: create a tag #contact by opening up the command pallet and typing that. Then go to that page and add some properties, like age, job, telephone number, address, etc. Then go to the journal and create a new node with someone’s name and type #contact. You will see those properties pop up. Fill in some test data. Do it again for another contact, then go back to the #contact page and see the table that is created.
Or you can open up Logseq DB and import this sample graph I made to see how it works.
My advice is to use #newtags sparingly rather than importing all your #tags as #newtags. They work best when creating a collection of related data: contacts, books, etc. where you want to create a table full of pre-filled properties for each item. Otherwise stick to [[pages]].