An Introduction to Dataview - Part 2

Dataview’s “contains” and related functions let Obsidian users filter notes by matching substrings, list membership, and even patterns in filenames and titles—turning everyday metadata into powerful, query-driven indexes. The core takeaway is that “contains” behaves differently depending on whether it’s applied to a single value or a list: on strings it checks for substring presence, but on arrays it only returns true when an exact element/object matches. That distinction matters because it changes what queries will work when metadata fields are multi-valued (like an authors list).

The session starts with practical examples of “contains.” A string query like “yes contains e” returns true, while “no contains e” returns false. The same idea extends to lists: a list [1,2,3] “contains 2” is true, while “contains 4” is false. From there, the discussion moves into real note filtering: building lists of daily notes by checking whether the filename contains a prefix/suffix (e.g., “dn” in the filename), or finding source notes by testing whether an authors field includes a specific author name (e.g., notes whose authors list contains “robert lamb”). A key caveat emerges when someone tries to “vectorize” contains across arrays: even if an authors field includes a substring match, the query won’t behave like substring search across list elements; it only succeeds when the exact object/value is present.

To handle date-like selection in titles, the conversation pivots to regular-expression-based matching. A common approach is using “regex match” (via rejects match) against file names or titles, with the regex crafted to match the entire string format. Participants note that you can still target substrings by shaping the regex (for example, using patterns that allow digits to appear in the right position). For example, selecting notes whose titles include a date can be done by matching a filename pattern with a four-digit year and two-digit month/day structure, or by using a field like file.day when available—where null results naturally fail the where condition.

The session then broadens into other aggregation and filtering functions. “Length” supports queries like “notes whose filename length is at least 20 characters” and “notes whose tags list length equals zero” to find untagged notes. “Sum” can add numeric lists, enabling workflows like totaling study time across repeated entries stored as list items. Questions about counting embedded items (like “blocking beds” or block embeds) highlight current limitations: Dataview can’t reliably access rendered embed content in live/preview contexts, and counting embedded elements may require workarounds such as link-based queries or regex detection, with some functionality only visible in edit mode.

Beyond functions, the discussion turns to data hygiene and maintainability. Participants compare manual curation versus dynamic “maps of content” generated from tags and templates. One attendee describes using a template (e.g., dataview mlc) to generate an index/map without cluttering graph views with real links, and sorting it by recently modified items. The group repeatedly returns to the same practical reality: Dataview’s power depends on consistent YAML metadata, and templates can reduce errors and repetitive maintenance. Finally, the session closes with guidance on contributing—using GitHub issues for feature requests/bugs, forking repositories, and updating documentation—so the plugin can evolve alongside user needs.