Unexpected Superfluous Search Results (due to whole word matching of properties)

Obsidian Version: 1.4.14

Platform: [Any]


I have recently updated to Obsidian version 1.4.14 and encountered an unexpected behavior while performing Properties searches with the built-in format (square brackets + double quotes). Prior to this update, I did not actively use the search feature, so I cannot confirm when this issue might have arisen.

Steps to Reproduce:

Open Obsidian version 1.4.14.
In the search bar, enter the following query or pick one of your properties from the pane, in my case: ["topic"] or, without the quotes [topic].

Expected Behavior:

The search results should only include notes containing the exact Property topic, as specified by the programmatic use of double quotes. No other related properties should be included in the search results, even if the word topic is included in others.

Actual Behavior:

Upon performing the search query ["topic"] or [topic], the results include the following Properties and their values:

topic: foo bar
parent_topic: fuu bar
child_topic: fuu baz
topic_alternative: fuuu baz

This behavior is unexpected and for me, appears to be not only inconsistent but misleading. It is not desired to have results that include properties other than topic and exactly that when the search query is enclosed in squared brackets and double quotes, explicitly pointing at the desired YAML key. I did not add a wildcard character or anything.

Additional information

My original poll:

Slightly surprised at being able to get results for ["topic_"] as well, because this is invalid for Properties keys themselves:



I am aware why it happens. and I recently found a connected problem in path operator.

It’s not really a bug, but I’ll talk with the team if we wanna change this.


The way it is right now, it’s like searching for tag2 and getting results for tag as well (I am omitting the tag search syntax here).
Reason I brought up tags is because they are not merely text strings, but more. Properties should be handled like tags: more than simple text. They are database elements (like back in the day we had in dBase: records, fields). “Elements” here means I don’t know the proper comp term. Which is why I was hesitant to put up the report in the first place…