The search string works for me: It returns all cards that have an empty field. Maybe it causes an error only in some situations (probably depending on your collection).
That makes sense. Presumably *: could be special cased to be a lot more efficient.
It also looks like we’re rebuilding the same regex for every field name comparison, which is quite wasteful.
I’d like to note that it does not solve the original problem I mentioned, which is that sql can send exceptions that are not catched and shown in an hard to understand way if you don’t know what sql is.
I love having *:foo as a special case, being able to easily search any field with an exact match. And "(?i)(^|\x1f){}($|\x1f)", seems reall cool (I don’t speak rust, but I still got the regexp part)
Well, this error could happen for a number of reasons, so it’s hardly possible to map it to a helpful user error. Instead we should take care that it doesn’t happen in valid use cases like yours in my opinion.
You can, at the very least, prefix it with a human message of the kind.
There was an error with the search. Please report the following message on forums.ankiweb.net
and maybe detect the “expression tree is too large” to indicate “or try a simpler search”
I think you couldn’t even be sure that it’s a search error, because it might have been other parts of Anki calling the database under the hood.
However, prefixing any unexpected errors with some helpful instructions sounds reasonable. Maybe this can be accomplished in the Python backend code without too much trouble.
You are right in principle Rumo, but I suspect a pragmatic approach could work here. I don’t recall any reports of this error being triggered outside the search code, so it’s probably not going to do much harm if we look for “Expression tree too large”, and convert the full text to something like “Search too complex, please simplify” in that case. Not thrilled about string comparisons, but I don’t think SQLite exposes a unique enum variant for us.