Find search terms in parent nodes as well

[Bjarke_Ebert]

I suggest an improved semantics of AND search (i.e. the default when there are multiple search terms)

Rationale: As this is a tree-based document system, often words in a parent node are not repeated in child nodes, since the child already lives in a context. But when searching, this context is not taken into account to find child nodes.

Example:

• A
• • B
• • C
• D
• • B
• • C
    When searching for B, I find all Bs in the document, which might be way too many to handle.
    When searching for A B, I find nothing.
    moo.do supports search for A B, where A and B are fulfilled at different levels.

Search for A_1 A_2 … A_n should match all nodes that have all the words somewhere between the node itself and the root of the document, and which contains at least one of the terms.

This would be a really useful feature.

[Leonardo_Muzkiz_Ramo]

"As this is a tree-based document system, often words in a parent node are not repeated in child nodes, since the child already lives in a context. "
yes.
this is a must !

[Bjarke_Ebert]

Maybe my example is a bit too abstract.
A better example could be a search for [ #TODO vacation ] which would find

+ Vacation plan
+  + ...
+  + ...
+  + book hotel #TODO

or searching for [schweiz tax] would find

+ My schweiz notes
+  + ...
+  + tax       <--- find this
+
+ My Denmark notes
+  +  tax    <-- not this

[Bjarke_Ebert]

I found this similar feature request

Children Inherit Parent Tags

Can each child/sub-item automatically inherit the tags associated with the parent (at least for search purposes)? That would make a huge difference using tags and searching across the board.

[Bjarke_Ebert]

Ping

Is this feasible to implement?

I often find myself wanting to search for two terms (foo bar), when there is a node with ‘bar’ that has a parent with ‘foo’.

Actually, I’m often not sure if (foo bar) will work or not, since ‘foo’ could also be in the sought node, but I think it should not matter if it is in the node itself, or in the “context” (parent nodes).

Without a feature like this it takes a lot more effort to find the right items.

[Erica]

@Bjarke_Ebert sorry just saw this somehow

Is this feasible to implement?

It’s feasible, but potentially very costly to check all levels of parent. If only the direct parent needs to be checked, it’s much easier and the results will appear much faster.

[Bjarke_Ebert]

Well, I think some smart use of indexing could make it fast enough. But it’s not so simple, though

In my opinion, checking only direct parents would be confusing - then better to keep the current semantics.

[Erica]

Well, I think some smart use of indexing could make it fast enough. But it’s not so simple, though

In my opinion, checking only direct parents would be confusing - then better to keep the current semantics.

We thought so too. Oh well, I hope we can come up with something soon. Thanks!

[Stephen_Dewitt]

Yes i frequently wish I had this feature too, but get the potential speed issue with so many possible combinations

[Erica]

If we only match direct parent (one level above), the performance would be acceptable, I think.

Not sure if that’s what people expect though.

[Michael_Phillips]

This seems similar to a problem that browser developers have to address to implement descendent selectors (https://www.w3.org/TR/2008/REC-CSS2-20080411/selector.html#descendant-selectors). Maybe there are similar approaches that would work for Dynalist.

[Erica]

This seems similar to a problem that browser developers have to address to implement descendent selectors (https://www.w3.org/TR/2008/REC-CSS2-20080411/selector.html#descendant-selectors). Maybe there are similar approaches that would work for Dynalist.

Do you mean having different syntax for children, descendants, and grandchildren?

[Michael_Phillips]

I was just thinking about the performance issues raised in your post above, and noting that browsers or other software products that support CSS selectors have to deal with the performance issues associated w/ descendants that may be some arbitrary number of levels below the parent node. I personally have no idea how they do this so my post is probably not that helpful!

[Erica]

I see, thanks for the input anyway! That’s definitely an interesting idea, having syntax to express what you need without having Dynalist assuming what you want.

Also CSS doesn’t prevent you from writing expensive selectors, it’s just that you need to bear that cost yourself. Same with Dynalist, the search happens in your browser/app and not our server, so the search is too slow, hopefully the user will consider editing it.

We should probably add a warning for the potentially slow queries though.

[Michael_Phillips]

That’s a good point

[Viktor_Papara]

I think I agree with @Bjarke_Ebert. It would be useful to have a sort of AND search that allows the words not to be in a single node but also finds them spread over several nodes but a single “branch”.

But I’m not sure I understand the discussion. @Erica, it sounds like you are talking about zooming into a node and performing a search. Right now, it only finds hits from this node and its children. Are you suggesting to include the parent into this search? Sort of, as if we zoomed into the parent instead of the node itself?

[Bjarke_Ebert]

As an experienced software engineer I would not worry too much about performance of this tree-aware search semantics.
For indexing, just pretend every ancestor is part of the node text. As long as the tree is not very deeply nested, this should not cause problems.
Heck, you could even do normal search for the most rare search term, then filter this search result using linear walkthrough with the more advanced semantics.

[Erica]

There’s no zooming involved. You could start from the root of the document or even do a search across all documents.

For example, current you can search for all items that contains “apple” in a document. If this feature were implemented, you’ll be able to search for items that contain “apple” who ALSO have a parent item that contains “fruit”. The search result set is a subset of the former case, if that makes sense.

But I understand what you mean as well – and I believe this discussion is not about where you search, but HOW you search. You still search under the current zoomed in item, that is not changed. It’s about adding a new way to limit results.

[Viktor_Papara]

Thanks for the clarification, @Erica.

You definitely have my vote for such a AND search possibility that doesn’t require the terms to be on the same node but in the same branch.

There is even another thread for such a functionality: Search Function: Greatest Common Parent. (AND + OR)

[Craig_Oliver]

For example, current you can search for all items that contains “apple” in a document. If this feature were implemented, you’ll be able to search for items that contain “apple” who ALSO have a parent item that contains “fruit”. The search result set is a subset of the former case, if that makes sense.

This would be a fantastic feature! I would use it daily.