On Wed, Feb 13, 2013 at 8:01 AM, Robert Muir <[email protected]> wrote: > On Wed, Feb 13, 2013 at 4:42 AM, Adrien Grand <[email protected]> wrote: >> Hi Shawn, >> >> On Tue, Feb 12, 2013 at 8:58 PM, Shawn Heisey <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
