On various pages I have property:: value1, value2, value3.
But doing a query like so: {{query (property topic value1)}} does not return any results.
So, to me that means you should only have 1 value per property, which is very restrictive. Am I right? Or is there a way to have more than 1 value on a property line AND extract each individually in a query?
This issue has come up a number of times in 1 form or another, but I have not seen an answer to my need.
I was looking into the same thing but I am intrigued by this:
I think we should be able to place multiple values in a property and they should become individual values for that property:
It works for dates, I don’t get a value of comma separated multiple dates as the case with the letters above:
I see this in config.edn:
" ;; By default, property value separated by commas will not be treated as
;; page references. You can add properties to enable it.
;; Example usage:
;; :property/separated-by-commas #{:alias :tags}
"
but I don’t really want to have to add here each property I create in a block which I want to be multi-value … :-/ . I believe Logseq should treat comma separated values as individual values…
It works with comma separated wikilinks (pages):
But I believe that, after I write a comma, after Logseq has recognized the first “Page” in the list, I get another pop-up to select another Value from the remaining List…
Multiple values per property are supported if put inside square brackets:
prop:: [[val1]], [[val2]], [[val3]]
I know that works, but it is not what I want: I don’t want to have separate pages created for each value.
So, if I understand well, it is not possible with non-bracketed values, correct?
The other option is to search for the value as a substring:
:where
[?b :block/properties ?props]
[(get ?props :prop) ?val]
[(str ?val) ?str]
[(clojure.string/includes? ?str "value1")]
Thanks for that.
I did this and got no result:
#+BEGIN_QUERY
{:title [:h3 "Value from multi-value"]
:query [:find (pull ?b [*])
:where
[?b :block/properties ?props]
[(get ?props :prop) ?val]
[(clojure.string/includes? ?val "value1")]
]
:remove-block-children? false
}
#+END_QUERY
What did I do wrong?
Should use the name of your own property in place of :prop.
Sorry to bug you again, but this is the output:
and this is the query:
#+BEGIN_QUERY
{:title [:h3 "Value from multi-value"]
:query [:find (pull ?b [*])
:where
[?b :block/properties ?prop]
[(get ?prop :topic) ?topic]
[(clojure.string/includes? ?topic "my-value")]
]
:remove-block-children? false
}
#+END_QUERYNo worries. I got that error earlier and edited my answer to cover such cases (those with mixed values), but I wasn’t fast enough. So please take the updated code.
That works! Thanks a lot for your help and patience 
I marked your amended code as the solution.
There is 1 more aspect I overlooked:
the query does not provide the page, even though in the settings it is enabled.
How can I get the page title added?
Are you looking for this?
[:find (pull ?p [*])
:where
[?b :block/page ?p]
[?b :block/properties ?prop]
[(get ?prop :topic) ?topic]
[(str ?topic) ?str]
[(clojure.string/includes? ?str "my-value")]
]
Yes, that is what I meant, thank you.
Looking at the syntax, I assume this query also looks for that value in block properties as well as page properties, correct?
It could use [?p :page/properties ?prop] instead, but currently it looks at :block/properties. It “just happens” that a page’s properties are themselves in a block (the first one in a page).
So, with :block/properties I get the properties in the 1st block as well as properties in other blocks on the page.
Amd if I would want to get only 1st block properties,
then in the syntax I would have to replace the line [?b :block/properties ?prop] with [?p :page/properties ?prop], correct?
Yes, but none is made for a specific use case (like the ones you describe). Think of them as available tools, which only try to serve the underlying data in some generic manner. If you are aware of their existence, there are many more ways to combine them and specify what you want to get.
OK, thanks for explaining this last bit. Its is clearer now.
Thank you.