Maybe I’m just cross-eyed right now, but a very simple dataview code doesn’t seem to be working since the properties update. I haven’t been using Obsidian in some months, so I’m new to the Properties update and anyways a bit rusty with all this. Probably I’m just not seeing what’s wrong.
Things I have tried
So, my dataview code looks like this (and I’ve tried variations with a FROM line, Table, etc). I seem to be able to generate results with the tags property, but nothing else:
List
WHERE Topics="Topic1"
Sort ASC
and I have a few notes with Topic1 as Topics property value, but I get “Dataview: No results to show for list query.”
Additionally, I have a couple other questions:
Can “Topics” in the above example for the property name be two words? E.g. Topic 1 or must it be one word, e.g. Topic_1 or Topic1
I also have a Property called “See_Also” which has linked pages, e.g. [[Page1]]. I want to do the query as above, but instead of a property value or a tags value, call any notes with [[Page1]] in the See_Also Properties. How is this coded?
One common issue lately has been where properties has changed from a single value into a list, so you need to check in one of your notes of a given topic how the topics is defined in source mode.
---
single_value: singleton
list_values:
- first
- second
---
Which displays as the following:
Here you see that the first value is just a single value, and the other is a list value with two items.
The “interesting” part is that even if the list_values property had only one item, you’d still need to use contains(list_values, "first") to check whether it was first. You can’t use list_values = "first" if the property is a list.
On a sidenote, if you got notes using both the single value and the list value variant, you need to convert all of them into the same format for your query to work. Something like contains(flat(list(single_value)), "singleton") would allow for the single_value property to be both just a single text property, or the list variant.
That was really helpful and solved both issues, one I didn’t yet know I had with the flattening!
That leaves me though with some confusion, something that came up long ago with this topic. I had been using variations of the following to be able to use AND and OR to combine tags, but doesn’t seem to work when using properties.
TABLE
item.ld as "Text"
FLATTEN file.lists as item
WHERE item.x
AND econtains(item.tags, "#ld/body/eyes")
OR econtains(item.tags, "#ld/body-type/tall")
Sort item.source ASC
or
TABLE
item.ld as "Text"
FLATTEN file.lists as item
WHERE item.x
AND econtains(item.tags, "#ld/body/hair")
AND econtains(item.tags, "#ld/body/eyes")
Sort item.source ASC
In this current issue I’m using something like this, but I’m not sure how to use And or Or as whatever I do, breaks the code.
LIST
WHERE econtains(Topics, "Topic1")
WHERE contains(flat(list(Note_Type)), "List")
Sort Date DESC
Lastly, how do I do the above for properties that contain pages, e.g. return all notes whose “See_Also” property contains [[Page1]]?
Lets simplify your test cases for a given case true AND false OR true. This will get a value, but it can be hard to understand which value it gets. So in most cases you’re better of using parentheses when introducing OR statements in such logic.
Both of these are clearer: true AND (false OR true) will return true. And (true AND false) OR true will also be true, but of a different reason if you follow my drift.
In your case if item.tags could contain either one of hair and eyes, I would write is as:
WHERE item.x
AND ( econtains(item.tags, "#ld/body/hair") OR
econtains(item.tags, "#ld/body/eyes") )
If you do multiple lines with WHERE ... they’re effectively AND’ed together.
I’m not entirely clear on your last issue, related to what you want out of it, how your markup looks, and a positive and negative example of results.
Hello. Wasn’t able to deal with this the last days, but thanks for this answer. But i got even more confused as I’m not using item.x in the current situation.
Basically, I’m trying to devise a system where I can pull up any combination of properties. e.g. pull up any “List” note on “Topic1” OR “Topic2”; or any “Wiki” note containing “Topic1” AND “Topic2”, etc. The below doesn’t work as I’m not sure how to structure all the different parentheses and flattening.
LIST
WHERE
AND ( econtains(Topics, "Terrorism") OR
(econtains(Topics, "Wars") AND
(econtains(flat(list(Note-Type)), "List") )
Sort Date DESC
This does work, but it’s an AND situation. What if I want to show any List note that has the Topics property as an OR situation?
LIST
WHERE econtains(Topics, "Terrorism")
WHERE econtains(Topics, "Wars")
WHERE econtains(flat(list(Note-Type)), "List")
Sort Date DESC
LIST
WHERE (econtains(Topics, "Terrorism") OR econtains(Topics, "Wars"))
AND econtains(flat(list(Note-Type)), "List")
Sort Date DESC
This should work as long as Topics are true lists.
It could be one trick to keep the OR statement on one line, to help you make sense of the parentheses. Then each line should have the same amount of opening and close parentheses.
This also allows for somewhat easier reading, as each line has to be true for the entire query to be true.
Can you clarify again what you mean by “as long as Topics are true lists.”? Meaning it’s not a field with a single value as described above? Otherwise I’d have to flatten?
On a similar but opposite issue: Originally, I only had a single-value Note-Type in my testing setup (“List”). But as I added more note types, e.g. List, Wiki, etc. then that field is no longer a single value. This code seems to work, but wanted to double check in case there’s something I’m not understanding.
LIST
WHERE (econtains(Topics, "Terrorism") OR econtains(Topics, "Wars"))
AND econtains(Note-Type, "Wiki")
Sort Date DESC
Basically, I took out the flattening as Note-Type is no longer a single value, but what’s confusing me is that is also works with the flattening as below. I figured that the below shouldn’t work if it’s not a single value field anymore.
LIST
WHERE (econtains(Topics, "Terrorism") OR econtains(Topics, "Wars"))
AND econtains(flat(list(Note-Type)), "Wiki")
Sort Date DESC
Yes…
Doing the flat(list( ... )) ensures that whatever field you’re using will be treated as a list. It’ll work nicely in both cases, both for single value fields and list fields. And it brings consistency to the table… again…
Slight correction: I used this code and it works, so is this flattened version preferable to cover all situation whether a list or single item?
LIST
WHERE (econtains(flat(list(Topics)), "Terrorism") OR econtains(flat(list(Topics)), "Wars"))
AND econtains(flat(list(Note-Type)), "Wiki")
Sort Date DESC
