This is a great tool and also for learning! Tnx for building it.
Great tips! thank you
1 Like
I would be interested why Clojure was chosen as a query language — is it how Logseq queries work internally, and that is exposed to the user?
Because to me, a visual query builder is a great, but i’d rather have something simple and text-based like the SQL-ish Obsidian Dataview: I would argue it is readable (and therefore: hackable) by most people.
1 Like
Yes, to my understanding the syntax comes from Datomic, that is an implementation in Clojure of Datalog query language, but Logseq uses a reimplementation that runs in the browser called DataScript.
Of course Advanced Queries are an additional feature for advanced users, there are already Simple Queries and the devs are interested in shipping a graphical query builder in the future, you can find a thread in this forum.
It’s a really cool experiment to let the user interact with the DB with the same query language the application uses internally.
You can do virtually everything with Advanced Queries if you have the skills and some time. You can even use Hiccup syntax to put results in HTML code. Basically you are remodeling the application.
Blurring the line between users and developers is a great idea to exponentially grow an application as a platform.
At the moment you can hack Logseq as a user by installing plugins, using templates, macros or in general combining the many features that are quite general and don’t impose a specific workflow.
You can hack it as a Web developer with custom CSS/JS, Hiccup/HTML or developing themes and plugins.
You can hack it as a Clojure developer of course but also by manipulating the Markdown/Org files programmatically or interacting with Logseq through its HTTP API (reading/writing JSON with whatever language).
Other applications claim to be “the everything OS” and stuff like that but the only one that could say such a thing is Logseq.
How cool is this?
I wouldn’t say SQL is simple, I’d say it’s better to have a graphical query builder, Simple Queries that already ships their own very simple language and Advanced Queries. In the future we could even have Machine Learning turning natural language into queries.
I tried Dataview plugin for Obsidian and personally I didn’t like it. I didn’t know Datalog at all before discovering Logseq and I am very happy to know that better alternatives to SQL exist and this one seems particularly useful with a graph database.
3 Likes
Thanks for you thoughts!
I wouldn’t say SQL is simple, I’d say it’s better to have a graphical query builder
Probably yes, all depends on how good the query builder UX is 
e.g. it would have to be a query editor (not just creating a query but also able to edit existing ones).
And having all those different input methods (simple queries, advanced queries and query builder) with different (visual or non-visual) languagues is confusing to me — should i “learn” simple queries, or when do i need advanced queries? Does the query builder do everything the advanced queries do?
Check my concept:
To my understanding, the Query Builder will be a graphical way to edit an Advanced Query.
Everything it’s impossible since an Advanced Query is based to a very powerful and expressive query language, it can take advantage of Clojure functions, transform results and style them with Hiccup/HTML. But I think it is supposed to be much more powerful than Simple Queries.
For now learn Simple Queries and ask for help with Advanced Queries, someone more proficient could write one for you and you can learn how to tweak it. Properly learning Advanced Queries is comparable to learning a programming language.
I don’t think a graphical Query Builder and a ML-powered natural language converter are too far into the future, hopefully some months. I tried to ask ChatGPT for Simple Queries and it worked very well.
Hi. See https://mschmidtkorth.github.io/logseq-msk-docs/#/page/queries%2Fadvanced%20queries%2Ftutorial for a couple of examples in that style. I’ve split up additional links into beginner vs advanced users to help beginner users find relevant tutorials - https://docs.logseq.com/#/page/advanced%20queries/block/additional%20links
3 Likes
As a non-coder my reply to this is…whaaaaaaat?
I seriously have no clue what a single one of those bullet points means and wouldn’rt even know where to begin 
Not a dig at you.
2 Likes
Advanced Queries will always be developer-oriented, instead the team is interested in providing a visual query builder for all the other users.
Nope, definitely it is not simple, but it can be. And it is for sure more natural language like then the advanced (or even simple) queries in Logseq. That is a very big plus for SQL and I think the biggest plus for SQL having done a lot of SQL work.
This is exactly the reason where I think Logseq is slowly becoming too technical for the ‘normal’ user. The thought that developers want to code everywhere in there live is (at least I think) is wrong, with some exceptions excluded off-course for people who self-write code to automate their coffee machine.
It is important that the language to query the data in Logseq should be logical, natural, explanatory with no need for non-natural language characters. I see at least in the forum a lot of extremely technical ways of doing things mentioned and also a focus on the most complex things that should be possble. Just look at the combine pages and blocks discussion. I think very few people read it all the way through. I hope the development teams keeps the simplicity (after all it is only a note-taking app right) in mind. Thank you.
1 Like
I mean it’s nothing the average user would use.
This is really a personal preference, I find SQL one of the worst thing ever in computing in general, while Datalog (or at least Datomic as implemented in Logseq) seems way more natural for me. For sure it’s way more powerful than SQL that is for relational databases, while here we have a graph database, that is way more flexible.
Maybe it’s not clear: Logseq is not going to introduce a whole new query language as powerful as Datalog. Being able to use Datalog is a feature like it’s a feature to use HTML or Markdown.
Logseq already provides a so called Domain-Specific Language (DSL), that is what we call Simple Queries.
Simple Queries are more or less macros for Datalog queries that cover very simple use cases.
Advanced queries will always be possible because it’s very powerful to be able to write as user the same queries Logseq uses internally, transform the results using Clojure functions and style the results as HTML via Hiccup syntax. Basically Advanced queries let you remodel Logseq.
Of course this is not what Logseq is supposed to be for average users. For them there will be other solutions, but it will takes more time. Simple Queries are already there as a patch and probably there will be a visual query builder and maybe even a Machine Learning-powered function that turn natural language into Datalog queries.
Logseq is not becoming too technical, Logseq started with many developer-oriented features and it aims to be usable also for the average users. In the meanwhile the advanced features are there because they were easier to implement and unlock a lot of power for skilled users. Those can also help other users by teaching tricks or even provide Advanced Queries on-demand, as it often happen on #queries channel on Discord.
These tools really are super. A big help.
I do have a couple of requests though. It does not seem possible to sort with your tools. Being able to sort by date added/modified would help me a huge amount.
Secondly, selecting only pages written within a range of dates would also help me a great deal.
If these could be added, I think I would suddenly be able to do everything I need to with your tools rather than just a fraction like now.
- Sorting
Tried adding sortby command but the result-transform function does not seem to work consistently from my testing. Theres no documentation about how result-transform works so reluctantly I left sorting out. I will include it once I can determine a generic code pattern from trawling through enough examples.
PS You can sort in table view by clicking columns
For created date sorting you can add these lines manually
ASCENDING ORDER
:result-transform (fn [result]
(sort-by (fn [h]
(get-in h [:block/created-at]) result)))
DESCENDING ORDER
:result-transform (fn [result]
(reverse(sort-by (fn [h]
(get-in h [:block/created-at])) result)))
:breadcrumb-show? false
- Pages between dates
Good idea … I’ll add it in the next release
1 Like
Sorting by :block/created-at in many cases is not meaningful because that date comes from the file’s metadata which comes with 2 problems:
- Not all pages have an actually file created. The file only gets created when you actually open the page and write something on it. If you only created a page-ref, then there is no file automatically created. That means that for pages without files, the created date will be reset every time you re-open Logseq.
- If you use Git, none of the files’ metadata get included in the repo, since git only version file contents, not metadata.
Because of that, what is more meaningful in my opinion is the journal date of when something was first mentioned.
1 Like
Thanks again! I also noticed that the result-transform function does not always give the results that I would expect.
I look forward to your next release
I was thinking it would be useful if result-transform could have a javascript function as its endpoint, since for many of us Javascript functions would be easier to work with than closure.
Thanks for the valuable info!
I tried to debug variable but didn’t succeed.
Can you please send full query that log variable so I can experiment with?
I probably doing something wrong.
Maybe I’m missing custom view thing.
Thanks 
1 Like
Being proficient in both languages now, I would say one is not inherently better, more logical or more natural than the other.
Both SQL and Datalog are powerful, and have their pro’s and cons.
SQL for a very basic query would look like.
select *
from table
where column = value
A very basic Datalog query can be written as.
{:query [:find (pull ?entity [*])
:where
[?entity column value]
] }
In SQL we need to know the table, while in Datalog ?entity represents a variable which Datalog will fill for us based on column and value.
In my opinion this syntax is not inherently better or worse, just different. Both queries basically do the same. Give all attribute for this table/entity where a specific column has a specific value.
For everyone I would recommend learning Datalog by starting with this basic intro tutorial. http://www.learndatalogtoday.org/
And look at the advanced queries documentation, which has been improved and also lists multiple extra resources. (https://docs.logseq.com/#/page/advanced%20queries)
Admittedly some technical affinity is needed to learn this. But there is always simple queries and asking others to help with more complex questions.
2 Likes
Late responder, but here’s my 2c because you’ve touched on something important here that I feel could be expanded on. I’d like to see LogSeq grow in it’s user-base and it’s improved accessibility in learning material.
I think most users come from a beginner software skill level. It all “clicked” for me once I had made an honest effort to learn Clojure and Datalog. Contrary to popular belief, knowledge of data structures are inherently not beginner friendly, but are necessary to realise the full LogSeq potential. I blame my own habitual complancency with all things “Data” onto the accessibility of Excel. Frankly, I don’t know what can be best done in this case, but looking backwards this is what I think could help:
- A detailed, embedded, easy-access, textbook-like reference guide (I’m talking 400pg user manual equivalent on top of the existing documentation… any volunteers people?)
- Somehow the new-user needs to be introduced to the ideas but also have an impressed appreciation on the required comprehension required to really take advantage of LogSeq.
- Holistic Examples. I found that holistic examples, like with graphs that included Advanced Queries, felt lacking or hidden. Sure there were simple examples, but I could not see the tangible results that people seemed to be so enthusiastic about in their graphs. It was too theoretical for my smoothness.
(elaboration below)
I’ve felt the way felt in the first post… up until a few days ago. The thing that changed was that I made a dedicated effort to try and learn clojure and datalog. My background is about 5 years of Mechanical Engineering. Coding experience is limited to Excel VBA. I am still learning and much of what I say is an opinion piece rather than an expert review.
Most users come from a beginner software skill level
I found that the resources for low-level LogSeq are difficult to digest and are spread out over various blogs. It does feel esoteric, which I think is a product to the fact that the content creators using the excellent but sporadic information on the forums / official docs. Big shoutout to the content creators for doing all of this in their own time by the way. I did become very motivated by the enthusiasm presented in videos and these discussion forums, but I didn’t get a tangible grasp on the thing that others were presenting. Content was either too simple (high level and conceptual youtube vides), or too complex (ambigious blogs whose authors evidently come from advanced coding backgrounds). I understand basic coding from uni and work, and given the early stage of LogSeq as an open source project I expect the average new user probably have ‘some’ form of conceptual understanding with coding.
It all “clicked” for me once I had made an honest effort to learn Clojure and Datalog
However in the last week I made a dedicated effort to master Datalog (which is the coding language that Advanced Queries use). Previously I only dabbled with these via templates, but I always struggled to make these queries relevant to my own graph. After studying the basic structure of “datoms” [^1] via many websites and getting to about level 10 of one of my learning resources (https://max-datom.com/) something clicked. I could suddenly comprehend Advanced Queries. I felt I had suddenly developed a sense of intuition into the whole system, much like one has when learning a language and then realising that you can suddenly follow conversation. I began playing around with the developer data which shows the datoms of your LogSeq graph. All of a sudden my graph and my use of it became so much less constrained, and the advanced resources online become user friendly. This leads me to suspect the weakness inherent in newstarters without a background in software…
([^1] Datoms are the data format that logseq database appears to use)
Contrary to popular belief, knowledge of data structures are inherently not beginner friendly, but are necessary to realise the full LogSeq potential
Now I must apologise because I’m a layman laying down big statements (so plug in a big opinionated “I think that…” in front of this paragraph title hahaha) but I think my frustration over available material versus my pace of understanding was because" the LogSeq DataLog framework was so alien to me as a beginner but I was biased to expect simplicity. I grew up under the convenient lens of excel, never questioning the complexity behind the tables, filters, and data relationships. Just bloody pivot table that beach… I think that its this fact that makes most people complacent (myself included) when trying to upgrade from using LogSeq as 1. a notepad and then 2. a data storage and manipulation tool; it’s too big a leap and quite frustrating when the average user thinks their knowledge of data systems is top tier (thanks to their certificate in “Excel - advanced conditional formatting”. What seems an accessible feature (even though it is under the category of advanced in LogSeq documents… damn my ego) is actually equivalent to the study one might expect in the 1st week of a uni course.
So really get the most out of LogSeq and it’s data, one has to try to learn the data structure and syntax behind it.
Frankly, I don’t know what can be best done in this case, but looking backwards this is what I think: (some of these are probably already implemented, but I’m just spitballing.
1. A detailed, embedded, easy-access, textbook-like reference guide for the advanced side of LogSeq data (including datalog and clojure docs).
2. I think it’s important to introduce some of these topics in a very beginner friendly way, and via a contents page, allow the reader to skip ahead. Somehow the new-user needs to be introduced to the ideas but also have an impressed appreciation to the required comprehension required to really take advantage of LogSeq. I think of my textbooks where I’d skip way ahead, have a moment of “nooope”, and then revert to the earlier chapters to try and recapture
3. Holistic Examples. These kinds of things are what really attracted me to LogSeq. Being able to see the way people used LogSeq and Advanced Queries, as well as the enthusiasm behind them. I found that holistic examples, like with graphs that included Advanced Queries, felt lacking or hidden. I could not see the tangible results that people seemed to be so enthusiastic about in their graphs. My failure oftenmost was in my attempt in copying and pasting Advanced Queries and then not getting an expected result due to my lack of understanding.
2 Likes
I made mention of it in my previous post. But I have a background in SQL. Like learning it in school in 2004-2008 and using it in my work until literally today 
And honestly… Datalog did not come easy to me, regardless that I have quite a good grip on data structure in a general sense.
But after 3 months I also had a moment it clicked. So I really do agree with you that it is not beginner friendly at all.
Hmmmm you make a good point. Maybe there is a way to use that entry way to explain concepts 
Yeah there should be a more concise, direct way to learn instead of sending users all over the place. A more Logseq minded way too. We can point at “general” tutorials and then users come back to Logseq with an expectation and then it turns out Logseq works just ever so slightly different.
I was actually having the idea yesterday. I realized that all the resources I offered in the Queries for Task management thread have become… buried in a way. Even when I go back there to find stuff to help people out in other threads I have a hard time finding stuff. And I wrote most of it 
So I had the idea that some of that was perhaps better shown and explained in a demo graph. Mind you that would be an effort… and I don’t have a lot of spare energy to work on such things. At the same time I think it might be a valuable resource as well.
It’s also one of the reasons I wanted to make a blog series about my own systems and workflows… though it has been… difficult to properly set it up. Even with my boyfriend proofreading and telling me he has no idea what I’m talking about haha.
I’m just not a very good writer of this kind of thing. So I just build advanced queries left and right 
try to add documentation here and there… hope for the best? 
Thanks for your edition, I really agree with your post.
2 Likes