Isn't this.file.link a dynamic equivalent of a wikilink to the file where the query is?

Help
1

280803747-5d7ab1c2-e701-4557-a6a6-6c9fc251236e
280803747-5d7ab1c2-e701-4557-a6a6-6c9fc251236e1446×216 12 KB

How can this query, which searches for files where a property contains a link to the current file, return 1000+ lines, even though there is only less than 10 files where the search criteria is acutally met? And as soon as I close the file with the query and reopens it, I get the expected result.

Is it a bug – or doesn’t this.file.link work the way I think it does, as a dynamic equivalent of using a wikilink in the search expression?

(This is a try to work around the fact that wikilinks in code-blocks doesn’t update automatically.)

2

I think your understanding of this.file.link is correct.

I have experienced a similar issue with the following query, where hub is a property that holds a wikilink to a “hub” note, i.e. a central note of a topic.

```dataview
TABLE
WHERE hub = this.hub AND file != this.file
SORT order ASC
```

Replacing hub = this.hub with hub.path = this.hub.path gives the same result.

It might be a good idea to file an issue to Dataview’s repo.

3

If you have a WHERE clause where parts of its value are null, you sometimes get the full list of notes from your vault (unless other criteria limits it).

In a test of mine if I did WHERE contains(Inbox, null) it returned all notes in my test vault, even though only one file actually had the Inbox property. In your case it could be that one the first edit the this.file.link didn’t have a proper value yet, so that it would use null and it returns all files. After the restart (after saving the file, allowing Obsidian to update metadata cache and so on), it got a value and did the proper match. Would this be considered a bug/feature, I’m not sure, but I’ve seen similar stuff happen every now and then.

Also in my test if I did WHERE Inbox AND contains(Inbox, null) it seems to behave slightly better and more in tune not displaying any result. Although I couldn’t get your original case to trigger in my test setup.

In summary, I think this strangeness could be related to the metadata cache still not being updated (or potentially the query cache causing the query to run with old metadata), and it seems to be countered by adding Inbox AND in front of the contains(). Possibly, to get it to refresh the query cache, you could add/remove spaces somewhere within the query code itself.

2 Likes