gerlowskija commented on PR #2499: URL: https://github.com/apache/solr/pull/2499#issuecomment-2155230712
I don't really think that's a fair characterization. The JIRA ticket was open and advertised to all of us on `issues@` 3 months ago, and no one chimed in there. Sometimes the brainstorming and feedback just doesn't appear until there's a 'patch' to stimulate it, so I wrote one 🤷 In any case, I'm happy to discuss/brainstorm the overall approach now. I think it stands on its own without considering "inertia". --- In short, my thought process was that the more broadly applicable the limit is, the more effective it will be at protecting stability. It's hard to achieve stability if the safeguards you're relying on are opt-in, "off" by default, or only apply to a subset of relevant queries. So I wanted to make the "minPrefix" limit be opt-out, apply broadly, etc. Solr already has a query-time limit that fits this "broadly applicable" model pretty well, also in service of stability: `maxBooleanClauses`. mBC has caused its share of issues, but the underlying model is sound and has been a part of Solr for at least a decade. Users are already familiar with this sort of limit coming in under solrconfig.xml, etc. So that's mostly what I've tried to do in this PR: (1) make it "broad" by design, and (2) follow mBC as a model in terms of how to configure, document, and implement. @dsmiley - You noted above your preference for something parser-specific. Can you elaborate on that preference a bit? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
