Return-Path: Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: (qmail 66359 invoked from network); 14 Sep 2010 19:43:02 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 14 Sep 2010 19:43:02 -0000 Received: (qmail 74478 invoked by uid 500); 14 Sep 2010 19:42:59 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 74426 invoked by uid 500); 14 Sep 2010 19:42:59 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 74418 invoked by uid 99); 14 Sep 2010 19:42:59 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Sep 2010 19:42:59 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [162.129.8.151] (HELO ipex2.johnshopkins.edu) (162.129.8.151) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Sep 2010 19:42:35 +0000 X-IronPort-AV: E=Sophos;i="4.56,366,1280721600"; d="scan'208";a="12404997" Received: from sys10.staff.ad.mse.jhu.edu (HELO [128.220.205.186]) ([128.220.205.186]) by ipex2.johnshopkins.edu with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2010 15:42:13 -0400 Message-ID: <4C8FD016.70402@jhu.edu> Date: Tue, 14 Sep 2010 15:42:14 -0400 From: Jonathan Rochkind User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "solr-user@lucene.apache.org" Subject: Re: Facet Field Value truncation References: <4C8FCE97.7080609@jimmy.harvard.edu> In-Reply-To: <4C8FCE97.7080609@jimmy.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Faceting on a multi-value field? I wonder if your positionIncrementGap for your field definition in your schema is 256. I am not sure what it defaults to. But it seems possible if it's 256 it could lead to what you observed. Try explicitly defining it to be really really big maybe? I'm not sure why it doesn't default to Really Really Big in the first place -- if it doesn't, not sure what it defaults to -- it's going to be much more common for people to assume Solr behaves like it does when it's Really Big, then for someone to actually want a small one. I was going to copy and paste some documentation on positionIncrementGap, but I can't find that either. It's at least included in the example schema.xml, so you can see where to put it. Jonathan Niall O'Connor wrote: > Hi, > Has anyone come across a situation where they have seen their facet > field values wrap into a new facet entry when the value exceeds 256 > characters? > > For example: > > > 2302 > 1403 > 1382 > > > 419 > 236 > 236* > > > As you can see the last value in the tissue-antology list is split > between two facet values. > > Should I open a bug for this? Or is this something configurable? > > Niall > > >