obsidian-dataview
obsidian-dataview copied to clipboard
blacksmithgu
Dataview parse error if tag contains some special charaters
What happened?
If I wrote a dv snippet to query a tag wihich contains some special charaters, like "." or "·" or "&" etc., dv shows error with following message.
Dataview: Error:
-- PARSING FAILED --------------------------------------------------
> 1 | list from #tagA.b
| ^
2 |
Expected one of the following:
'and' or 'or', /FROM/i, EOF, FLATTEN <value> [AS <name>], GROUP BY <value> [AS <name>], LIMIT <value>, SORT field [ASC/DESC], WHERE <expression>, text
DQL
list from #tagA.b
JS
No response
Dataview Version
0.5.38
Obsidian Version
0.14.15
OS
Windows
I don't think that is a specific Dataview issue. Why? Because I guess you're talking about a tag created in frontmatter... Something like:
---
tags: tag.1
---
If you try to write the tag in the middle of you note content, Obsidian doesn't recognize the #tag.1, only #tag (.1 remain separated from the recognized tag). Because they're some prohibited characters.
For dataview the field tags: in frontmatter remains as a normal field (with the key-name "tags") and "tag.1" is recognized as a value. It is Obsidian that recognize the field with the name "tag" or "tags" and convert the values to real file tags.
In the case, I guess Obsidian is able to recognize tag.1 as #tag.1 if the value is in a tag field in frontmatter, but don't recognize #tag.1 if in the main content.
Based in the normal behavior (tags in content) I guess the developer followed the obsidian rules and did not consider the possibility of "prohibited" characters in tags when in from/source command.
Dataview will actually parse the tags correctly in this case, but the query parser doesn't understand the '.' specifically. This seems a little hard to fix in general, especially if Obsidian allows you to use arbitrary characters. I'll have to experiment.
I wonder if we can temporarily get around this by using a where condition. Seems like it should work in theory.
I don't think that is a specific Dataview issue. Why? Because I guess you're talking about a tag created in frontmatter... Something like:
--- tags: tag.1 ---If you try to write the tag in the middle of you note content, Obsidian doesn't recognize the
#tag.1, only#tag(.1remain separated from the recognized tag). Because they're some prohibited characters.For dataview the field
tags:in frontmatter remains as a normal field (with the key-name "tags") and "tag.1" is recognized as a value. It is Obsidian that recognize the field with the name "tag" or "tags" and convert the values to real file tags. In the case, I guess Obsidian is able to recognizetag.1as#tag.1if the value is in a tag field in frontmatter, but don't recognize#tag.1if in the main content.Based in the normal behavior (tags in content) I guess the developer followed the obsidian rules and did not consider the possibility of "prohibited" characters in tags when in from/source command.
YES , I was using the tags in frontmatter. OBSIDIAN could recognize it and find out all notes who have this tag.
Yes, as said before Obsidian recognize it if in the frontmatter. As suggested by @AB1908, you can contour this with the WHERE condition (however in performance side isn't the same thing, I guess). By two ways: 1 - by "file.tags" or "file.etags"
WHERE contains(file.tags, "#tag.1")
2 - by "tags" (or "tag", i.e. the key you write in frontmatter):
WHERE contains(tags, "tag.1")
if only one tag per file you can use WHERE tags = "tag.1" instead of contains.
Yes, as said before Obsidian recognize it if in the frontmatter. As suggested by @AB1908, you can contour this with the WHERE condition (however in performance side isn't the same thing, I guess). By two ways: 1 - by "file.tags" or "file.etags"
WHERE contains(file.tags, "#tag.1")2 - by "tags" (or "tag", i.e. the key you write in frontmatter):
WHERE contains(tags, "tag.1")if only one tag per file you can use
WHERE tags = "tag.1"instead of contains.
Thank you! This could solved my problem.