I have this simple query:
#+BEGIN_QUERY
{:title [:h3 "Word search — case insensitive"]
:query
[:find (pull ?b [*])
:in $ ?input
:where
[(str "(?i)" ?input) ?pattern]
[?b :block/content ?c]
[(re-pattern ?pattern) ?q]
[(re-find ?q ?c)]]
:inputs ["search term"]
}
#+END_QUERY
The results are all in duplicate: why is that? I thought it was only a quirk of the simple query {{query "search term"}}, so I used the above, but it still happens.
Same here. No duplicates. (Yes I have search term in my test graph lol)
Though this result is quite interesting 
I had the {{query hidden}} too, though I did not put it there so I deleted it, not that it changed anything. I do not get the “Block Renderer Error”.
I does not happen with a small graph, so I guess it must be something in my graph that is not right.
To detect the cause of the problem, you have two options:
I’ll hold off with option 2. 
As an example, I have made a screenshot of a page that gives duplicate search results. Here is the original page, which is a journal page:
The search term is ardis, which occurs in the Covid section:
So, my question is: do you see anything odd in the way I have put the text in the journal page (1st screenshot) that might give the duplicate result (2nd screenshot)?
I removed the block, which only occurs on the 2023-10-05 page. However, the search result dropped 1 “copy” of the ardis block, but still shows 1 copy, even though there is no ardis text on the 2023-10-05 journal page!
.md file of that journal in another editor, to inspect its contents..md file and create a fresh one.Yes, that worked fine.
Ah yes, the famous re-index. So, after removing the block and its children, I re-indexed, and the search result was empty.
Adding the blocks back in only gives 1 result!! So, removing, re-indexing, adding back in seems to have fixed it. I tried a few other search terms and there were no duplicates.
So, once again, many thanks for your guidance and patience.
There is just 1 question that remains: what was wrong? Or perhaps I should ask: after what actions should I re-index?
I have the impression I did something in the past that required a re-index but that I omitted.
If we knew that, the system would re-index by itself, or not mess-up to begin with. You may find some patterns with experience, but it is generally a matter of imperfect implementation.
don’t do that! The query hidden shows up to say that block contains a query that has been hidden. (So we don’t render queries in an endless cycle)
It is what @mentaloid says.
Whenever I notice something wrong with my graph and the files look fine, and going to All pages > three dots > remove orphaned pages does not help, I’ll re-index just to be sure.
But it’s good to hear it is solved now.
From what I understand, with the db version that will not be an issue anymore. So, I’ll have to see if I can even use the db version when it is out.
Thanks for your help, I will mark your earlier reply as the solution.
It does not show up in the renewed Word search query, nor does it show up in any of the other queries I have always open.
So, when/from where is the hidden query syntax added?
It just means the block in the query result is itself a query. And instead of rendering the query it says it has hidden it.
In my example the block that shows that looks like this:
But why does Logseq do that? What is the advantage?
Performance and preventing getting caught in an endless loop. For example if a query has itself as its result.
OK, understood, thank you.
