Implement relation name wildcard feature

[misch334]

Trilium Notes currently has the limitation, that one needs to explicitely specify the kind of relation to query for, when using search dialog. Users need to actively

• decide, if a link is internal (embedded in note content) or an explicit relation - causing friction during dumping of thoughts
• remember, which link type has been chosen, in order to retrieve desired note connections

Intent of this PR is to reduce this mental load of users. It also strives to align Trilium Notes with other Note taking apps.An example is Logseq, where page links can be unformely queried, regardless if properties (akin to Trilium explicit relations) are used or in-content links. Further filtering by properties is just optional.

I used a dummy database with note size of 10.000 to test performance (let me know, if shell script for dummy note creation is of interest). There wasn't any noticeable delay in search dialog in combination with relation wildcard search ~?.

[gemini-code-assist]

Summary of Changes

Hello @misch334, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the search functionality within Trilium Notes by introducing a relation name wildcard. This allows users to perform more flexible and intuitive searches, retrieving notes connected by any type of relation—whether explicit or an internal link—without needing to specify the exact relation name. The change simplifies the search process, making it easier to discover related content and reducing cognitive overhead for users.

Highlights

• New Feature: Relation Name Wildcard: Introduced a new search capability allowing users to query for notes connected by any relation, including internal links, using the ~? syntax.
• Improved User Experience: This feature aims to reduce the mental load on users by eliminating the need to remember specific relation types when searching for connected notes, aligning Trilium Notes with other modern note-taking applications.
• Performance Optimization: Performance was tested with a database of 10,000 notes, and no noticeable delay was observed when using the relation wildcard search.
• Documentation and UI Updates: The English translation file, search definition options in the UI, and the user guide documentation have all been updated to reflect and explain the new ~? search syntax.
• New Test Coverage: A new test file, relation_where.spec.ts, has been added to ensure the correct functionality and behavior of the relation name wildcard search.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog

• apps/client/src/translations/en/translation.json
  • Added new translation keys for 'relation_xyz' and 'relation_wildcard' to support the new search syntax examples.
• apps/client/src/widgets/ribbon/SearchDefinitionOptions.tsx
  • Updated the search help dialog to include examples for specific relation search (~xyz) and the new wildcard relation search (~?).
• apps/server/src/services/search/expressions/relation_where.spec.ts
  • Added a new test file to verify the functionality of the relation name wildcard search, ensuring it correctly identifies notes with both internal links and explicit relations.
• apps/server/src/services/search/expressions/relation_where.ts
  • Defined RELATION_NAME_WILDCARD as '?' to represent the wildcard character for relation names.
  • Modified the execute method to check for the RELATION_NAME_WILDCARD and, if present, iterate over all attributes to find relations; otherwise, it uses becca.findAttributes for a specific relation name.
  • Exported RELATION_NAME_WILDCARD for use in other modules.
• docs/User Guide/User Guide/Basic Concepts and Features/Navigation/Search.md
  • Updated the user guide to include examples of the new relation search syntax, specifically ~internallink.title = Tolkien, ~?.title = Tolkien, and ~?.ancestors.title = Tolkien.

Activity

• No human activity (comments, reviews) has been recorded on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a useful wildcard search for relations, allowing users to query for any relation type. The implementation is mostly solid, with additions to the search syntax documentation and new tests. I've identified a potential performance improvement in the wildcard search logic and a couple of minor style inconsistencies. Overall, a great addition to Trilium's search capabilities.

[misch334]

One thing to add: By “lexer” this module is meant. Its operators are used to split the tokens, hence e.g. * was not possible to use as relation name wildcard.

Currently this lexer returns an array of tokens. Later on it might be extended as “more sophisticated” lexer to also return token type identifiers, like REL_NAME_WILCARD for char ? within relation name. These enriched tokens then can be interpreted more flexibly by parse.ts.

Though this PR seems sufficient for now.

[misch334]

Another alternative is to add conditional logic for the token seqence ~? (Relation ~ + whatever symbol the relation wildcard has, here ?) in lexer, so that wildcard is not mis-interpreted as one of the lexer operators. But this change would only be needed, if we should decide to re-use an existent operator symbol like *.

With ? it works without any lexer modifications, and question mark is easily interpreted as wildcard, hence I am in favor of it.