search

zadam / trilium

Build your personal knowledge base with Trilium Notes
GNU Affero General Public License v3.0
27.2k stars 1.9k forks source link

Search on inherited attributes fails #2457

Closed DHMike57 closed 2 years ago

DHMike57 commented 2 years ago

Preflight Checklist

Trilium Version

0.48.8

What operating system are you using?

Other Linux

What is your setup?

Local + server sync

Operating System Version

arch linux

Expected Behavior

with notes

searchstring testfind #foo #bar should return the leaf note testfind. searchstring new #foo #bar should only return the parent note new note

Actual Behavior

new #foo #bar returns both, testfind #foo #bar returns only the parent.

If I add the attributes to the leaf

then testfind #foo #bar works as expected, although new .... still returns both. Presumably the path is being searched. (design decision or oversight?). For me, at least, this is not desirable.

I also have a scenario where with inherited attributed searches #foo #bar and #bar #foo give different results, but I cannot reproduce it in a small test case.

Additional Information

No response

zadam commented 2 years ago

Hi,

Presumably the path is being searched. (design decision or oversight?). For me, at least, this is not desirable.

This is intended, consider e.g. paths like "Journal \ 2021 \ 11 - November" or "Work \ Projects" - it seems very natural to search for "work projects" or "November 2021". In a sense the note's path is part of note's primary identity.

testfind #foo #bar returns only the parent.

Although I can't reproduce this specific behavior, your report brought me to discover a bug in exactly this setup. It's now fixed and now the search returns "testfind" note as expected.

DHMike57 commented 2 years ago

Thanks for the quick fix, Zadam. I can confirm that not only the bug I described above is fixed, but also the obviously related one that I was unable to reproduce in a small test case.

I managed to figure out how to launch the dev-mode desktop successfully from sources (I am not familiar with the node ecosytem, and it is a monster!) but I could not get the linux build script to work. I tried

sudo npm install -g n
n i 16.13.1   ; seemed to work
npm install   ; also tried prefixing these with n i 16.13.1
npm update
./bin/build-linux-x64.sh

The build produced an error in the npx webpack ... line, with Module not found: Error: Can't resolve 'fs' There was a build produced, which I could run: I could see it talking to the database in the terminal, but the trilium screen was completely blank.

I appreciate you may not want to support home builds, but if something is obvious to you I'd be obliged for any suggestions. I can use the dev mode but it's a bit clunky and I am assuming it will be a while before the next binary release. I can't mix and match because of database version incompatibility.

This is intended, consider e.g. paths like "Journal \ 2021 \ 11 - November" or "Work \ Projects" - it seems very natural to search for "work projects" or "November 2021". In a sense the note's path is part of note's primary identity.

I hadn't thought of it that way (more that the note's identity was its database entry and that the path was one of potentially several handy places to display it). I must have another think about possibilites for organising things!

zadam commented 2 years ago

It would be more advisable to build from stable branch (which also contains the attribute search fix) and AFAIK doesn't have that "fs" problem, master branch contains potentially unstable code.

Alternatively just wait for next patch release from stable branch, probably in the next few days.

DHMike57 commented 2 years ago

Nice and easy, built perfectly. My db was unreadable as a future version, but easily cured by swapping in yesterday's daily backup. Many thanks, closing this as fixed.