Regex Suggestions are not correct.

[hwine]

I had a basic regex query that worked, but returned hits in doc files, so I tried to add some qualifiers to better target files. At that point, two things happened:

1. the search was declared "too expensive"
2. An error about possible boolean operator in query was reported, with a suggested fix that raised the same errors.

Screen Shot

Even though the search was deemed "too expensive", it did return partial results (THANKS), showing that "and" was being interpreted as text to search for. Turns out we use that word quite a bit in our docs. 😄

After experimenting a bit, the correct suggestion is to remove the AND operators, and rely on the implicit AND between terms. That still yields the "too expensive" warning, but provides enough data to start to work with.

[colinwm]

That's strange, I think your query confused our parser somehow. I'll look into it

[colinwm]

Also, just as a hint to improve query performance, this query is very difficult to satisfy because it does not contain any ngrams for us to search for. The only characters you're looking for here are : and @. If it's possible to add e.g. a term (at least 3 characters long) to the query that shows up in all matching documents (or e.g. the paths of matching documents), it will make the query a LOT faster!

[colinwm]

@hwine thanks for the report! I've fixed the bug with the parser. Might be worth trying again (and as I suggested, adding some more terms to the query to make it more specific, if possible!)

[hwine]

Thanks much for the quick turnaround, and the performance hints. We're greatly looking forward to the API. 😁

Re ngrams -- the catch is it needs to work for any URI scheme, including the odd ones like data base connection strings. Would it help to have a list of alternatives? e.g. (roughly, not tested): (https?|s3|mysql): or does the 2 character 's3' negate the effect?

Given how many false positives this search gives, CS may not be the correct tool for the job, beyond finding 100 files that need further investigation. 😄 But - that's a lot better than I had before!

[colinwm]

Alternatives are definitely useful. E.g. I believe our regex engine is smart enough to decompose (https?|s3|mysql):// into ngram searches for http:// or https:// or s3:// etc.

[hwine]

Thanks -- always a good day when I learn something new ;) I'll give that a try.