Saved Searches: Recursing hierarchical searches

[ownedbycats]

EDIT: "Recursing" probably isn't the right word here. I was thinking more of something similiar to the the divide-and-conquer algorithm, where a task is split up into a bunch of smaller tasks and then combined back together.

I've been starting to split up my monstrous long "Cleanup" saved search. However, I just wanted to make sure this wouldn't cause any issues.

Example: If I have this hierarchy:

Cleanup
Cleanup.Missing Metadata
Cleanup.Missing Metadata.Missing Page Count
Cleanup.Missing Metadata.Missing Language
Cleanup.Fanfiction
Cleanup.Fanfiction.Fanfics with Errors

Would there be any problem if I nested these?

Cleanup would be
search:"=Cleanup.Missing Metadata" OR search:"=Cleanup.Fanfiction"

While Cleanup.Missing Metadata would be
search:"=Cleanup.Missing Metadata.Missing Page Count" OR search:"=Cleanup.Missing Metadata.Missing Language"

This seems like the best way to split it up, but I don't want to break things!

[ownedbycats]

I split it successfully (saved my monster search to a text file in case I need to revert it). Works right so long as all the subsearches are valid. But splitting it up makes it easier to track down where an error is.

Performance seems to be a bit better too. There was a tiny lag on my old search that's gone now.

[chaley]

Originally Posted by ownedbycats

EDIT: "Recursing" probably isn't the right word here. I was thinking more of something similiar to the the divide-and-conquer algorithm, where a task is split up into a bunch of smaller tasks and then combined back together.

The right word is "nesting", and as you discovered there isn't a problem with that.

Recursion means X uses itself to compute the answer; X calls X directly or indirectly. Recursion requires that X have a "termination condition"; a situation where X returns a value instead of calling X. This allows the call chain to undo and return a value. If there is no termination condition then X will call X forever, eventually running out of memory or some other resource. Saved searches do not have termination conditions so recursion is not allowed by the search parser.

This Wikipedia article discusses recursion both formally and informally.

[ownedbycats]

The only issue I found with the nesting is that you can't omit a subsearch, e.g.
search:"=Cleanup" AND NOT search:"=Cleanup.Missing Metadata.Missing Pagecount"
will come up invalid, presumably because Cleanup (indirectly) calls Missing Pagecount—seems intentional enough that I won't file a bug report over it. But I can just do an OR search for all the subsearches except Missing Pagecount.

[chaley]

The check-for-recursion test is approximate because the search parser doesn't maintain a call (recursion) stack. Instead it uses the heuristic that a search must be recursive if the search expression executes the same saved search more than 5 times. For example, this search doesn't fail:

search:"b" or search:"b" or search:"b" or search:"b" or search:"b"

but this search does fail:

search:"b" or search:"b" or search:"b" or search:"b" or search:"b" or search:"b"

Assuming your searches aren't actually recursive, my guess is that is what is happening to you.

[ownedbycats]

Cleanup contains (search:"=Cleanup.Missing Metadata"), and Cleanup.Missing Metadata contains (search:"=Cleanup.Missing Metadata.Missing Pagecount").

I did test the recursion though just to see what would happen - two searches called foo and bar that try to call each other results in a red invalid search border.

[chaley]

When you get a recursion error the tooltip on the search box tells you what saved search calibre has seen more than 5 times.

[chaley]

I changed the "recursion" limit count from 5 to 10.