Dataview and nested tags not working any more

I use a dataview query as follows:

TABLE WITHOUT ID as "Agenda",comment AS ""
FROM #dashboard/agenda
SORT asc

This has been working fine until recently. Now it just shows the message “Dataview: No results to show for table query.”

The problem seems to be with the nested tags. It works if I just use #dashboard, but not #dashboard/agenda.

I have tried changing it to a Table with ID, and even LIST, but it won’t work with the nested tag any more.

On the Blacksmithgu Github page it still gives the following as an example:

LIST FROM #games/mobas OR #games/crpg

So I can’t see any reason why it has stopped working for me. It won’t work on any of my devices, and the dataview plugin is up to date.

@niall I don’t know the answer, and I can’t get the same behavior to happen after updating dataview, but here’s something I was doing to try to figure out what was happening in my own vault: Could you add a column file.tags AS "Tags" to your table for #dashboard that does display results? That will list all the tags for each file in the table cell, so if there are many other tags in your files with the #dashboard tag you might want to use WHERE or LIMIT to show a smaller number of files in this testing table. Does the full #dashboard/agenda tag show up in the table row for the appropriate files?

That’s odd. I just upgraded to the latest version of Dataview, and this query seems to be working for me. Am I doing something different than you?


That looks exactly the same as what I’m doing. I don’t know what’s happened. It was working, and now it’s not.

1 Like

Doing that does display the tags, including all my dashboard tags.

I have Multiple dashboard tags (agenda, people, books) that I use to build a workspace. I only tag a few files at a time to show, so it shouldn’t be an issue with quantity.

I might just have to change them to dashboard_agenda so it’s not a nested tag.

1 Like

That is odd! I got the same results as @Craig , and it sounds like Obsidian is finding all your tags. Good luck and I would love to know if you figure it out!

Ah! It seems the problem lies in the way I use tags in the Front Matter.

I have been using something similar to this:

tags: [" #dashboard/people #work #friend "]

And it has been working well until recently. Now it doesn’t show anything. If I change it to:

tags: ["#dashboard/people", "#work", "#friend"]

It works again. So there must have been a change in the way Obsidian or Dataview deals with tag arrays. ??

The behavior of frontmatter version of tags seems finicky. I have mine listed as tags: [work, topic/subtopic] etc without the hashtags or the quotes but definitely as separate list items! I don’t remember whether I got that from the Obsidian help or a forum post here. I know that hashtags without quotes is bad in the frontmatter - it’s interesting to see that quotes make them work!

Yes, that seems plausible, if it was before looking for tags with “contains” for example. Thank you for providing the best example I’ve seen of what that mysterious “Function Vectorization” comment at the top of the Functions page for DQL means! The rest of this post is purely for conceptual interest, no practical advice.

What is Function Vectorization?
Let’s make 2 items in some test page’s frontmatter, using the example from your post (but without the # since I want to have 2 items so they can’t both be called tags):

thing1: [" dashboard/people work friend "]
thing2: ["dashboard/people", "work", "friend"]

thing1 is a list containing a single string and thing2 is a list containing 3 strings; we can show this in a table:

TABLE thing1, length(thing1), thing2, length(thing2)
FROM "testFolder"
WHERE thing1

You’ll likely see one bullet under thing1 and bullets next to each of the three items in thing2, and the lengths are 1 and 3 respectively. Possible other experiments (aka dataview table rows to make): turn each thing explicitly into a string of text via string(thing1) or via join(thing1, "!!! ") and see what they look like and their length. Can you change the join function call to get the same behavior as string?

Do my fields contain “work”?
Ok back to what you actually wanted to do - find out whether some word/item/string of text is inside these things! From the Functions page again, contains(object|list|string, value) will check to see if the value is in the object, list, or string and return an answer of true or false. I am confident that if I add a row to my dataview table with contains(thing2, "work") the answer will be true since “work” is one of the three items in thing2’s list. But thing1 only has one item in its list - that whole long string! If thing1 was just a long string without the [] around it, I would also be confident that contains(" dashboard/people work friend ", "work") would have an answer of true. If we weren’t using dataview, it would just be too bad that long string is inside a list. But, Dataview function vectorization to the rescue! From the very top of that Functions page,

Most functions can be applied either to single values (like number, string, date, etc.) OR to lists of those values.

So contains will be applied to each of the strings inside each of the lists and both thing1 and thing2 will give answers of true!!!

thing1, thing2, 
contains(thing1, "work") AS "work in 1?",
contains(thing2, "work") AS "work in 2?"
FROM "testFolder"
WHERE thing1

Note: “AS blah” just renames the column header to make it shorter, you can take it out.
This seems to match the old behavior you were getting with tags.

Variations (aka more table rows to try): Do either thing1 or thing2 contain “work friend”? What about the exact item “work”? (Use econtains instead of contains for an exact match; it’s not documented on the Functions page yet but it exists in the updated dataview plugin.) What string do you have to use instead of “work” to get econtains(thing1, "work") to give an answer of true? Do any modifications or additions you can think of to thing1 and thing2 and see if the answers to queries in this post still match your expectations.

Guess with no evidence behind it: maybe dataview switched to using econtains to check for tags?
Perhaps one of the experts in this forum can answer!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.