Closed DHMike57 closed 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.
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!
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.
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.
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 notetestfind
. searchstringnew #foo #bar
should only return the parent notenew 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, althoughnew ....
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