Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of yseeley@gmail.com designates
 209.85.128.172 as permitted sender)
MIME-Version: 1.0
Sender: yseeley@gmail.com
In-Reply-To: 
 <CAOdYfZWtVNDPkxfmVxHBYKiyFCWR1MxX7qcX1SF+qhPiQm5JVA@mail.gmail.com>
References: <511A9EEF.2090204@elyograg.org>
	<CAPsWd+PQ4ySrXj27A3xNCJ0=D-9fcOB71v0hTLG1E-Ld40e_eg@mail.gmail.com>
	<CAOdYfZWtVNDPkxfmVxHBYKiyFCWR1MxX7qcX1SF+qhPiQm5JVA@mail.gmail.com>
Date: Wed, 13 Feb 2013 10:14:39 -0500
Message-ID: 
 <CAB_8Yd93WNOtU8yjHY+_2=rNPsb=RqmXu_Xu=FqMb0qA0am9kA@mail.gmail.com>
Subject: Re: New Lucene features and Solr indexes
From: Yonik Seeley <yonik@lucidworks.com>
To: dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Feb 13, 2013 at 8:01 AM, Robert Muir <rcmuir@gmail.com> wrote:
> On Wed, Feb 13, 2013 at 4:42 AM, Adrien Grand <jpountz@gmail.com> wrote:
>> Hi Shawn,
>>
>> On Tue, Feb 12, 2013 at 8:58 PM, Shawn Heisey <solr@elyograg.org> wrote:
>>> Some of these, like compressed stored fields and compressed termvectors, are
>>> being turned on by default, which is awesome.  I'm already running a 4.2
>>> snapshot, so I've got those in place.
>>
>> Excellent!
>>
>>> One thing that I know I would like to do is use the new BloomFilter for a
>>> couple of my fields that contain only unique values.  Last time I checked
>>> (which was before the 4.1 release), if you added the lucene-codecs jar, Solr
>>> had a BloomFilter postings format, but didn't have any way to specify the
>>> underlying format.  See SOLR-3950 and LUCENE-4394.
>>
>> BloomFilterPostingsFormat is a little special compared to other
>> postings formats because it can wrap any postings format. So maybe it
>> should require special support, like an additional attribute in the
>> field type definition?
>
> -1
>
> Instead of making other APIs to accomodate BloomFilter's current
> brokenness: remove its custom per-field logic so it works with
> PerFieldPostingsFormat, like every other PF.
>
> In other words, it should work just like pulsing.
>
> I brought this up before it was committed, and i was ignored. Thats
> fine, but I'll be damned if i let its incorrect design complicate
> other parts of the codebase too. I'd rather it continue to stay
> difficult to integrate and continue walking its current path to an
> open source death instead.

Would your desired changes in bloom postings format change the high
level interface in Solr (i.e. specifying bloom on a field or fieldType
in the schema)?
If not, any currently needed work-around seems more like an
implementation detail.

-Yonik
http://lucidworks.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org