orgzly
Feature/search leaf nodes
Implementation for feature: Search expression to match only "leaf" notes #1059
Using two queries to get only the leaf notes when the search input includes h.leaf (leaf hierarchy).
The first SQL query works as usual. If it's a leaf search, it's saved in the Options property called searchLeafNotes.
Inside selectNotesFromQueryLiveData, once this property is checked and we get the NoteView LiveData array based on other criteria, the process maps them into a list of Long note IDs. Then, another SQL query runs to recursively find child notes from the original search. Finally, it filters out any notes that are parents of another note in the results, leaving only the leaf notes.
Tested with the following inputs:
- t.tag2 h.leaf
- fold h.leaf
- i.todo h.leaf
t.work
Can you please explain this more in depth? I only set up the leaf option as of this date on hierarchy type. So the query with this option on will make all the query then perform the search leaf notes and filter out the parents. The order of the input doesn't affect the result as far as I am aware. Example: fold h.leaf, fold and h.leaf, h.leaf fold, fold (h.leaf), (fold) h.leaf , (fold h.leaf) all return the same result.
Edit: The leaf notes means that it will only return the very end children of the search query, all the parents and intermediate children do not make part of the end result. They are filtered out.
t.work
Can you please explain this more in depth? I only set up the leaf option as of this date on hierarchy type. So the query with this option on will make all the query then perform the search leaf notes and filter out the parents. The order of the input doesn't affect the result as far as I am aware. Example:
fold h.leaf,fold and h.leaf,h.leaf fold,fold (h.leaf),(fold) h.leaf,(fold h.leaf)all return the same result.
Sure - what I mean is that the leaf part is more a condition than an option, so we want it to behave like tag, or state for example.
This would mean we can then look for notes which are either:
- tagged with "work" (while not necessarily a leaf note)
- leaf-notes which are tagged with "gift"
(in the above example, t.work or (b.gifts and h.leaf)), rather than it being an all-or-nothing option, if you see what I mean?
t.work
Can you please explain this more in depth? I only set up the leaf option as of this date on hierarchy type. So the query with this option on will make all the query then perform the search leaf notes and filter out the parents. The order of the input doesn't affect the result as far as I am aware. Example:
fold h.leaf,fold and h.leaf,h.leaf fold,fold (h.leaf),(fold) h.leaf,(fold h.leaf)all return the same result.Sure - what I mean is that the leaf part is more a condition than an option, so we want it to behave like tag, or state for example.
This would mean we can then look for notes which are either:
- tagged with "work" (while not necessarily a leaf note)
- leaf-notes which are tagged with "gift"
(in the above example,
t.work or (b.gifts and h.leaf)), rather than it being an all-or-nothing option, if you see what I mean?
Now I understand. I will have a look at this case.