Feature/search leaf nodes #1067
Conversation
…furthest children notes of the search query ONLY
…ds long type formatted
bobrippling
left a comment
bobrippling
left a comment
There was a problem hiding this comment.
Nice work! I wonder - what will happen when the leaf query isn't at the top level, for example: t.work or (b.gifts and h.leaf) ?
| if (days > 0) options.copy(agendaDays = days) else null | ||
| }, | ||
| OptionMatch("""^(\.)?h\.(.+)""") { match, options -> | ||
| if (match.groupValues[2].lowercase() == HyerarchyType.LEAF.toString().lowercase()) |
There was a problem hiding this comment.
Perhaps the file that defines HyerarchyType is missing?
There was a problem hiding this comment.
I will check this out Bob.
There was a problem hiding this comment.
Also, the HierarchyType enum class was not added into the Git commit. As it was part of a previous iteration to solve this problem.
I am working on it
There was a problem hiding this comment.
Added HierarchyType and fixed its name typo (before, it was spelled incorrectly as HyerarchyType)
There was a problem hiding this comment.
Nice, thanks! I guess the filename just needs the typo change too?
There was a problem hiding this comment.
I fixed the typo
There was a problem hiding this comment.
Youre right the file name sorry I will fix it ASAP
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: 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. |
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:
(in the above example, |
…yType) enum class to HierarchyType.kt
Now I understand. I will have a look at this case. |
|
@TheAttentionSeeker5050 @bobrippling Hi guys, this project has been abandoned for three years now. There is an active fork here: https://github.com/orgzly-revived/orgzly-android-revived Feel free to open a PR! |
|
Thanks @amberin! For reference / anyone following, the corresponding orgzly-revived issue is here: orgzly-revived/orgzly-android-revived#653 |
3 participants
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: