Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 77F82200CAB for ; Sun, 18 Jun 2017 23:42:10 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 765FA160BE3; Sun, 18 Jun 2017 21:42:10 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id BCC2D160BD1 for ; Sun, 18 Jun 2017 23:42:09 +0200 (CEST) Received: (qmail 1876 invoked by uid 500); 18 Jun 2017 21:42:08 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 1866 invoked by uid 99); 18 Jun 2017 21:42:08 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 18 Jun 2017 21:42:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 4FF08C23B2 for ; Sun, 18 Jun 2017 21:42:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.011 X-Spam-Level: X-Spam-Status: No, score=-100.011 tagged_above=-999 required=6.31 tests=[SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id YwLZsAyWE63y for ; Sun, 18 Jun 2017 21:42:07 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 120075FB6A for ; Sun, 18 Jun 2017 21:42:07 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id A3905E00A3 for ; Sun, 18 Jun 2017 21:42:05 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 43B5C23FFE for ; Sun, 18 Jun 2017 21:42:02 +0000 (UTC) Date: Sun, 18 Jun 2017 21:42:02 +0000 (UTC) From: "Adrien Grand (JIRA)" To: dev@lucene.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (LUCENE-7880) Make boolean query clause limit configurable per-query MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Sun, 18 Jun 2017 21:42:10 -0000 [ https://issues.apache.org/jira/browse/LUCENE-7880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053319#comment-16053319 ] Adrien Grand commented on LUCENE-7880: -------------------------------------- Mark, what is your proposal? This issue looks like a tentative to workaround the fact that there was disagreement about removing the limit entirely in LUCENE-4835. However adding a per-query API feels even worse to me. It adds an unnecessary method to one of the main classes of our API, and will contaminate many other classes like query parsers, maybe MoreLikeThis, etc. if we want to be able to set different limits on boolean queries that these classes generate too. > Make boolean query clause limit configurable per-query > ------------------------------------------------------ > > Key: LUCENE-7880 > URL: https://issues.apache.org/jira/browse/LUCENE-7880 > Project: Lucene - Core > Issue Type: Improvement > Reporter: Yonik Seeley > > As we know, the magic BooleanQuery.maxClauseCount has bitten many people over time. > It's also a static, which really hurts multi-tenancy (i.e. we can't have different settings for different users, clients, or use-cases). > If we want to keep this static as a default, then at least we should allow it to be overridden on a per-query basis when we know it is the desired behavior and not a bug. > Perhaps the simplest way to achieve this would be a setter on BooleanQuery.Builder that configures the limit for that instance only? -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org