Re: forceMerge(1) leads to ~10% perf gains

[Ishan Chattopadhyaya]

Also, try index sorting. Often, there are performance gains to be had with
the right sort key for various query workloads.

On Fri, 22 Sept, 2023, 4:28 pm Adrien Grand,  wrote:

> > Was wondering - are there any other techniques which can be used to speed
> up that work well when forceMerge works like this?
>
> Lucene 9.8 (to be released in a few days hopefully) will add support
> to recursive graph bisection, which is another thing that can be used
> to speed up querying on read-only indices.
>
> https://github.com/apache/lucene/pull/12489
>
> On Fri, Sep 22, 2023 at 12:54 PM Uwe Schindler  wrote:
> >
> > Hi,
> >
> > Yes, a force-merged index can be faster, as less work is spent on
> > looking up terms in different index segments.
> >
> > If you are looking for higher speed, non-merged indexes can actually
> > perform better, IF you parallelize. You can do this by adding an
> > Executor instance to IndexSearcher
> > (<
> https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/search/IndexSearcher.html#%3Cinit%3E(org.apache.lucene.index.IndexReader,java.util.concurrent.Executor)
> >).
> > If you do this each segment of the index is searched in parallel (using
> > the thread pool limits of the Executor) and results are merged at end.
> >
> > If an index is read-only and static, fore-merge is a good idea - unless
> > you want to parallelize.
> >
> > Tokenizing and joining with OR is the correct way, but for speed you may
> > also use AND. To further improve the speed also take a look at Blockmax
> > WAND: If you are not interested in the total number of documents, you
> > can get huge speed improvements. By default this is enabled in Lucene
> > 9.x with default IndexSearcher, but on Solr/Elasticsearch you may need
> > to actively request it. In that case it will only count exact number of
> > hits till 1000 docs are found.
> >
> > Uwe
> >
> > Am 22.09.2023 um 03:40 schrieb qrdl kaggle:
> > > After testing on 4800 fairly complex queries, I see a performance gain
> of
> > > 10% after doing indexWriter.forceMerge(1); indexWriter.commit(); from
> 209
> > > ms per query, to 185 ms per query.
> > >
> > > Queries are quite complex, often about 30 or words, of the format OR
> > > text:
> > >
> > > It went from 214 to 14 files on the forceMerge.
> > >
> > > It's a 6GB static/read only index with about 6.4M documents.
> Documents are
> > > around 1MB or so of text.
> > >
> > > Was wondering - are there any other techniques which can be used to
> speed
> > > up that work well when forceMerge works like this?
> > >
> > > Is there a better way to query and still maintain accuracy than simply
> word
> > > tokenizing a sentence and joining with OR text: ?
> > >
> > --
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >
> > -
> > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: java-user-h...@lucene.apache.org
> >
>
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>

[ANNOUNCE] Apache Lucene 8.4.1 released

[Ishan Chattopadhyaya]

## 13 January 2020, Apache Lucene™ 8.4.1 available

The Lucene PMC is pleased to announce the release of Apache Lucene 8.4.1.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release is
available for immediate download at:

  

### Lucene 8.4.1 Release Highlights:

(No Changes since 8.4.0)



Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not have
replicated the release yet. If that is the case, please try another mirror.
This also applies to Maven access.

-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

[ANNOUNCE] Apache Lucene 8.3.1 released

[Ishan Chattopadhyaya]

## 3 December 2019, Apache Lucene™ 8.3.1 available

The Lucene PMC is pleased to announce the release of Apache Lucene 8.3.1.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release is
available for immediate download at:

  

### Lucene 8.3.1 Release Highlights:

  * Bugfix: MultiTermIntervalsSource.visit() was not calling back to its visitor

Please read CHANGES.txt for a full list of changes:

  

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not have
replicated the release yet. If that is the case, please try another mirror.
This also applies to Maven access.

-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

[ANNOUNCE] Apache Lucene 8.3.0 released

[Ishan Chattopadhyaya]

## 2 November 2019, Apache Lucene™ 8.3.0 available

The Lucene PMC is pleased to announce the release of Apache Lucene 8.3.0.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release is
available for immediate download at:

  

### Lucene 8.3.0 Release Highlights:

  * New SpanishMinimalStemFilter
  * New "export all terms and doc freqs" feature to Luke with delimiters
  * Composite Matches from multiple subqueries now allow access to
their submatches, and a new NamedMatches API allows marking of
subqueries and a simple way to find which subqueries have matched on a
given document
  * Range Query For Multiple Connected Ranges
  * LatLonDocValuesPointInPolygonQuery for LatLonDocValuesField
  * New UniformSplitPostingsFormat (name "UniformSplit") primarily
benefiting in simplicity and extensibility
  * New STUniformSplitPostingsFormat (name "SharedTermsUniformSplit")
that shares a single internal term dictionary across fields
  * DisjunctionMaxQuery more efficiently leverages impacts to skip
non-competitive hits
  * BooleanQuery with no scoring clause can now early terminate the
query when the total hits is not requested
  * Matches on wildcard queries will defer building their full
disjunction until a MatchesIterator is pulled
  * spatial-extras quad and packed quad prefix trees now index points faster
  * Add additional leaf node level optimizations in LatLonShapeBoundingBoxQuery
  * Improve performance of WITHIN and DISJOINT queries for Shape
queries by doing just one pass whenever possible
  * Introduce shared count based early termination across multiple slices
  * Blocktree's seekExact now short-circuits false if the term isn't
in the min-max range of the segment. Large perf gain for ID/time like
data when populated sequentially
  * Show SPI names instead of class names in Luke Analysis tab
  * GraphTokenStreamFiniteStrings preserves all Token attributes
through its finite strings TokenStreams
  * Introduced SpanPositionRange into XML Query Parser
  * Use a sort key instead of true distance in NearestNeighbor
  * Tessellator labels the edges of the generated triangles whether
they belong to the original polygon
  * Use exact distance between point and bounding rectangle in
FloatPointNearestNeighbor
  * The Korean analyzer now splits tokens on boundaries between digits
and alphabetic characters
  * MoreLikeThis is biased for uncommon fields


Please read CHANGES.txt for a full list of new features and changes:

  


Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not have
replicated the release yet. If that is the case, please try another mirror.
This also applies to Maven access.

-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

[ANNOUNCE] Apache Lucene 8.1.0 released

[Ishan Chattopadhyaya]

16 March 2019, Apache Lucene™ 8.1.0 available

The Lucene PMC is pleased to announce the release of Apache Lucene 8.1.0.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for
nearly any application that requires full-text search, especially
cross-platform.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release is
available for immediate download at:

http://lucene.apache.org/core/mirrors-core-latest-redir.html

Lucene 8.1.0 Release Highlights:

 * A query introspection API has been introduced.
 * Luke, well-known GUI for inspecting Lucene indexes, now added as a
Lucene module
 * Merging dimensional points to use radix partitioning, which has
also been optimized
 * Bugfix: LatLonShapePolygonQuery returns incorrect WITHIN results
with shared boundaries
 * TieredMergePolicy#findForcedMerges now tries to create the cheapest merges
 * Build point writers in the BKD tree only when they are needed
 * SynonymQuery can now deboost the document frequency of each term
when blending synonym scores
 * ConstantScoreQuery can early terminate if minimum score > constant
score (total hits are not requested)
 * DateRangePrefixTree can now parse more precise dates

Further details of changes are available in the change log available
at: http://lucene.apache.org/core/8_1_0/changes/Changes.html

Please report any feedback to the mailing lists
(http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring
network for distributing releases. It is possible that the mirror you
are using may not have replicated the release yet. If that is the
case, please try another mirror. This also applies to Maven access.

-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Re: CVE-2018-11802: Apache Solr authorization bug vulnerability disclosure

[Ishan Chattopadhyaya]

This fix has also been backported to Solr 6.6.6 for users who are
stuck with Solr 6.x.

(Sorry, I hadn't updated the issue and hence this was missed in the
original mail.)

On Wed, Apr 24, 2019 at 12:35 PM Noble Paul  wrote:
>
> CVE-2018-11802: Apache Solr authorization bug disclosure
> Severity: Important
> Vendor: The Apache Software Foundation
> Versions Affected: Apache Solr 7.6 or less
>
> Description:
> jira  ticket : https://issues.apache.org/jira/browse/SOLR-12514
> In apache Solr the cluster can be partitioned into multiple
> collections and only a subset of nodes actually host any given
> collection. However, if a node receives a request for a collection it
> does not host, it proxies the request to a relevant node and serves
> the request. Solr bypasses all authorization settings for such
> requests. This affects all Solr versions that uses the default
> authorization mechanism of Solr (RuleBasedAuthorizationPlugin)
>
> Mitigation:
> A fix is provided in Solr 7.7 version and upwards. If you use Solr's
> authorization mechanism, please upgrade to a version newer than Solr
> 7.7.
>
> Credit: This issue was discovered by Mahesh Kumar Vasanthu Somashekar.
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

[ANNOUNCE] Apache Lucene 6.6.6 released

[Ishan Chattopadhyaya]

5 April 2019, Apache Lucene™ 6.6.6 available

The Lucene PMC is pleased to announce the release of Apache Lucene 6.6.6.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

This release contains no change over 6.6.5. The release is available
for immediate download at:

https://www-us.apache.org/dist/lucene/java/6.6.6/

Please read CHANGES.txt for a full list of changes:

https://lucene.apache.org/core/6_6_6/changes/Changes.html

Please report any feedback to the mailing lists
(http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not have
replicated the release yet. If that is the case, please try another mirror.
This also applies to Maven access.

-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Apache Lucene 7.7.1 released

[Ishan Chattopadhyaya]

= 1 March 2019, Apache Lucene™ 7.7.1 available =

The Lucene PMC is pleased to announce the release of Apache Lucene 7.7.1.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

This release contains one bug fix. The release is available for immediate
download at:

http://lucene.apache.org/core/mirrors-core-latest-redir.html

Lucene 7.7.1 contain no changes over Lucene 7.7.0.

Please report any feedback to the mailing lists (
http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also applies to Maven access.

Re: Grant Ingersoll's 2009 blog article- is there a newer version?

[Ishan Chattopadhyaya]

Try these, maybe?

https://lucidworks.com/2017/09/14/solr-payloads/
http://www.textsearch.io/?p=5

On Thu, Jul 5, 2018 at 8:26 PM,  wrote:

> Hi,-
>  Is there a newer version of this great article from Mr. Grant Ingersoll?
>
>  https://lucidworks.com/2009/08/05/getting-started-with-payloads/ Thanks
>
> This article is based on Lucene 2.9.
> Best regards
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>

[ANNOUNCE] Apache Lucene 6.6.5 released

[Ishan Chattopadhyaya]

03 July 2018, Apache Lucene™ 6.6.5 available

The Lucene PMC is pleased to announce the release of Apache Lucene 6.6.5.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

This release contains no changes over 6.6.4. The release is available for
immediate
download at:
http://lucene.apache.org/core/mirrors-core-latest-redir.html

Further details of changes are available in the change log available at:
http://lucene.apache.org/core/6_6_5/changes/Changes.html

Please report any feedback to the mailing lists (
http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also applies to Maven access.

[ANNOUNCE] Apache Lucene 6.6.4 released

[Ishan Chattopadhyaya]

18 May 2018, Apache Lucene™ 6.6.4 available

The Lucene PMC is pleased to announce the release of Apache Lucene 6.6.4.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

This release contains one bug fix. The release is available for immediate
download at:
http://lucene.apache.org/core/mirrors-core-latest-redir.html

Further details of changes are available in the change log available at:
http://lucene.apache.org/core/6_6_4/changes/Changes.html

Please report any feedback to the mailing lists (
http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also applies to Maven access.

[ANNOUNCE] Apache Lucene 6.6.4 released

[Ishan Chattopadhyaya]

18 May 2018, Apache Lucene™ 6.6.4 available

The Lucene PMC is pleased to announce the release of Apache Lucene 6.6.4.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

This release contains one bug fix. The release is available for immediate
download at:
http://lucene.apache.org/core/mirrors-core-latest-redir.html

Further details of changes are available in the change log available at:
http://lucene.apache.org/core/6_6_4/changes/Changes.html

Please report any feedback to the mailing lists (
http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also applies to Maven access.

[ANNOUNCE] Apache Lucene 6.6.2 released

[Ishan Chattopadhyaya]

18 October 2017, Apache Lucene™ 6.6.2 available

The Lucene PMC is pleased to announce the release of Apache Lucene 6.6.2.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

This release contains numerous bug fixes, optimizations, and improvements,
some of which are highlighted below. The release is available for immediate
download at:

http://lucene.apache.org/core/mirrors-core-latest-redir.html
Please read CHANGES.txt for a full list of new features and changes:

https://lucene.apache.org/core/6_6_2/changes/Changes.html

This release includes a critical security fix. Details:

* Disallow resolving of external entities in queryparser/xml/CoreParser by
default.

Further details of changes are available in the change log available at:
http://lucene.apache.org/core/6_6_2/changes/Changes.html

Please report any feedback to the mailing lists (
http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also applies to Maven access.

Re: Re: What is the fastest way to loop over all documents in an index?

[Ishan Chattopadhyaya]

I believe that's the case. Leave the deleted docs out, though (which can be
computed by intersecting with some other bitset.).

On Tue, Sep 5, 2017 at 2:04 PM, Ahmet Arslan <iori...@yahoo.com> wrote:

>
> Hi Ishan,
>
> I saw following loop is suggested for this task in the stack overflow.
>
> for (int i=0; i<reader.maxDoc(); i++)
>
> How can we confirm that internal Lucene IDs are subsequent numbers from 0
> to maxDoc()-1?
>
> I thought that they are arbitrary integers.
>
> Ahmet
>
>
>
>
> On Tuesday, September 5, 2017, 7:54:31 AM GMT+3, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>
>
>
>
> Maybe IndexReader#document(), looping over docids is the best here?
> http://lucene.apache.org/core/6_6_0/core/org/apache/lucene/
> index/IndexReader.html#document-int-
>
> On Tue, Sep 5, 2017 at 7:57 AM, Ahmet Arslan <iori...@yahoo.com.invalid>
> wrote:
>
> > Hi Jean,
> >
> > I am also interested answers to this question. I need this feature too.
> > Currently I am using a hack.
> > I create an artificial field (with an artificial token) attached to every
> > document.
> >
> > I traverse all documents using the code snippet given in my previous
> > related question. (no one answered to it)
> >
> > http://lucene.472066.n3.nabble.com/PostingsEnum-for-
> > documents-that-does-not-contain-a-term-td4349482.html
> > I found EverythingEnum class in the Lucene50PostingsReader.java, but I
> > couldn't figure out how to use it.
> > So, I do not know if this class is for the task, but its name looks
> > promising.
> > Thanks,Ahmet
> >
> >
> >
> > On Tuesday, September 5, 2017, 3:09:37 AM GMT+3, Jean Claude van Johnson
> <
> > vanjohnsonjeancla...@gmail.com> wrote:
> >
> >
> >
> >
> >
> > Hi there,
> >
> > I have an use case, were I need to iterate over all documents in an index
> > from time to time.
> > It seems that the MatchAllDocsQuery is what I should use for this,
> however
> > it creates a bunch of Objects (Score etc) that I don’t really need.
> >
> > My question to you is:
> >
> > What is the fastest way to loop over all documents in an index?
> > Is it looping over all possible doc id’s (+filtering out deleted
> > documents)?
> >
> > Thank you very much.
> >
> > Best regards
> > Claude
> >
>

Re: What is the fastest way to loop over all documents in an index?

[Ishan Chattopadhyaya]

Maybe IndexReader#document(), looping over docids is the best here?
http://lucene.apache.org/core/6_6_0/core/org/apache/lucene/index/IndexReader.html#document-int-

On Tue, Sep 5, 2017 at 7:57 AM, Ahmet Arslan 
wrote:

> Hi Jean,
>
> I am also interested answers to this question. I need this feature too.
> Currently I am using a hack.
> I create an artificial field (with an artificial token) attached to every
> document.
>
> I traverse all documents using the code snippet given in my previous
> related question. (no one answered to it)
>
> http://lucene.472066.n3.nabble.com/PostingsEnum-for-
> documents-that-does-not-contain-a-term-td4349482.html
> I found EverythingEnum class in the Lucene50PostingsReader.java, but I
> couldn't figure out how to use it.
> So, I do not know if this class is for the task, but its name looks
> promising.
> Thanks,Ahmet
>
>
>
> On Tuesday, September 5, 2017, 3:09:37 AM GMT+3, Jean Claude van Johnson <
> vanjohnsonjeancla...@gmail.com> wrote:
>
>
>
>
>
> Hi there,
>
> I have an use case, were I need to iterate over all documents in an index
> from time to time.
> It seems that the MatchAllDocsQuery is what I should use for this, however
> it creates a bunch of Objects (Score etc) that I don’t really need.
>
> My question to you is:
>
> What is the fastest way to loop over all documents in an index?
> Is it looping over all possible doc id’s (+filtering out deleted
> documents)?
>
> Thank you very much.
>
> Best regards
> Claude
>

Re: Encryption at lucene index

[Ishan Chattopadhyaya]

Harry Ochiai (Hitachi) has some index encryption solution,
https://www.slideshare.net/maggon/securing-solr-search-data-in-the-cloud
I think it is proprietary, but I'm not sure. Maybe more googling might help
find the exact page where his solution is described.

On Mon, Aug 7, 2017 at 9:59 PM, Kumaran Ramasubramanian 
wrote:

> Hi Erick, i want to encrypt some fields of an document which has personal
> identifiable information ( both indexed and stored data)... for eg: email,
> mobilenumber etc.. i am able to find LUCENE-6966 alone while googling it..
> any related pointers in solr or latest lucene version?
>
>
> -
> ​-
> Kumaran R​
>
> On Mon, Aug 7, 2017 at 9:52 PM, Erick Erickson 
> wrote:
>
> > No, since you haven't defined what you want to encrypt, what your
> > requirements are, what you hope to get out of "encryption" etc.
> >
> > Put the index on an encrypting filesystem and forget about it if you
> > possibly can, because anything else is a significant amount of work.
> > To encrypt the searchable tokens on a per-user basis in memory is a
> > _lot_ of work. It depends on your security needs.
> >
> > Otherwise, as I said, please ask specific questions as the topic is
> > quite large, much too large to conduct a seminar through the user's
> > list.
> >
> > Best,
> > Erick
> >
> > On Mon, Aug 7, 2017 at 9:07 AM, Kumaran Ramasubramanian
> >  wrote:
> > > Hi Erick,
> > >
> > > Thanks for the information. Any pointers about encryption options
> in
> > > solr?
> > >
> > >
> > > --
> > > Kumaran R
> > >
> > >
> > >
> > > On Mon, Aug 7, 2017 at 9:17 PM, Erick Erickson <
> erickerick...@gmail.com>
> > > wrote:
> > >
> > >> Encryption in Solr has a bunch of ramifications. Do you care about
> > >>
> > >> - encryption at rest or in memory?
> > >> - encrypting the _searchable_ tokens?
> > >> - encrypting the searchable tokens per-user?
> > >> - encrypting the stored data (which a filter won't do BTW).
> > >>
> > >> It's actually a fairly complex topic the discussion at LUCENE-6966
> > >> outlines much of it. Please ask specific questions as you research the
> > >> topic. One  per-user encryption package that I know of is by Hitachi
> > >> Solutions (commercial) and it explicitly does _not_ support, for
> > >> instance, wildcards (there are other limitations too). See:
> > >> http://www.hitachi-solutions.com/securesearch/
> > >>
> > >> Most of the time when people ask for encryption they soon discover
> > >> it's much more difficult than they imagine and settle for just putting
> > >> the indexes on an encrypting file system. When they move beyond that
> > >> it gets complex and you'd be well advised to consult with Solr
> > >> security experts.
> > >>
> > >> Best,
> > >> Erick
> > >>
> > >> On Sun, Aug 6, 2017 at 11:30 PM, Kumaran Ramasubramanian
> > >>  wrote:
> > >> > Hi All,
> > >> >
> > >> >
> > >> > After looking at all below discussions, i have one doubt which may
> be
> > >> silly
> > >> > or novice but i want to throw this to lucene user list.
> > >> >
> > >> > if we have encryption layer included in our analyzer's flow of
> filters
> > >> like
> > >> > EncryptionFilter to control field-level encryption. what are the
> > >> > consequences ? am i missing anything basic?
> > >> >
> > >> > Thanks in advance..
> > >> >
> > >> >
> > >> > Related links:
> > >> >
> > >> > https://issues.apache.org/jira/browse/LUCENE-2228 : AES Encrypted
> > >> Directory
> > >> > - in lucene 3.x
> > >> >
> > >> > https://issues.apache.org/jira/browse/LUCENE-6966 :  Codec for
> > >> index-level
> > >> > encryption - at codec level, to have control on which column / field
> > have
> > >> >  personal identifiable information
> > >> >
> > >> > https://security.stackexchange.com/questions/
> > 53/is-a-lucene-search-
> > >> index-effectively-a-backdoor-for-field-level-encryption
> > >> >
> > >> >
> > >> > A decent encrypting algorithm will not produce, say, the same first
> > >> portion
> > >> >> for two tokens that start with the same letters. So wildcard
> searches
> > >> won't
> > >> >> work. Consider "runs", "running", "runner". A search on "run*"
> would
> > be
> > >> >> expected to match all three, but wouldn't unless the encryption
> were
> > so
> > >> >> trivial as to be useless. Similar issues arise with sorting. "More
> > Like
> > >> >> This" would be unreliable. There are many other features of a
> robust
> > >> search
> > >> >> engine that would be impacted, and an index with encrypted terms
> > would
> > >> be
> > >> >> useful for only exact matches, which usually results in a poor
> search
> > >> >> experience.
> > >> >
> > >> >
> > >> > https://stackoverflow.com/questions/36604551/adding-
> > >> encryption-to-solr-lucene-indexes
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Kumaran R
> > >>
> > >> -
> > >> To unsubscribe, e-mail: 

[ANNOUNCE] Apache Solr 6.6.0 released

[Ishan Chattopadhyaya]

6 June 2017, Apache Solr 6.6.0 availableSolr is the popular, blazing
fast, open source NoSQL search platform from the Apache Lucene
project. Its major features include powerful full-text search, hit
highlighting, faceted search and analytics, rich document parsing,
geospatial search, extensive REST APIs as well as parallel SQL. Solr
is enterprise grade, secure and highly scalable, providing fault
tolerant distributed search and indexing, and powers the search and
navigation features of many of the world's largest internet sites.Solr
6.6.0 is available for immediate download at: .
http://lucene.apache.org/solr/mirrors-solr-latest-redir.htmlPlease
read CHANGES.txt for a full list of new features and changes: .
https://lucene.apache.org/solr/6_6_0/changes/Changes.htmlSolr 6.6
Release Highlights:Fields and field types:* Payload support with
payload() value source and {!payload_score} and {!payload_check}
query parsers* Solr support for SimpleTextCodec, via   in solrconfig.xml (per-field
specification in the schema is not possible)* Multi-field support to
TermsComponent when requesting terms' statistics* Grouping support
with PointFields* CollapseQParser support with PointFields*
ExpandComponent support with PointFieldsNew API:* UPLOAD command
(Config Set API) for uploading zipped configsets* MOVEREPLICA command
(Collections API) for moving a replica across nodes* LISTALIASES
command (Collections API) to return a list of all collection aliases*
STATUS command (Core Admin API) to emit collection details of each
coreScript:* Basic authentication can be enabled/disabled using
bin/solr|bin/solr.cmd* ls command to ZkCLI for listing only
sub-directories* bin/solr script now prints warning when available
system entropy is lower than 300* solr.in.sh installed by install
script should be writable by solr userFaceting:* Variance and Standard
Deviation aggregators for the JSON Facet API* JSON Faceting now
supports a query time 'join' domain change optionStreaming expressions
and evaluators:* CartesianProductStream, which turns a single tuple
with a multi-valued field into N tuples, one for each value in the
multi-valued field* Basic math Streaming Evaluators* UUID Streaming
Evaluator* Date/time Stream Evaluators* analyze Stream Evaluator to
support streaming NLP* shuffle Streaming Expression* search Streaming
Expression should work in non-SolrCloud mode* echo Streaming
Expression* eval Streaming Expression* timeseries Streaming
Expression* let, get and tuple Streaming Expressions* Correlation
Stream Evaluator* stats Streaming Expression should work in
non-SolrCloud mode* regress and predict Stream Evaluators* covariance
Stream Evaluator* convolution Stream Evaluator* normalize Stream
EvaluatorExamples:* Solr default/example uses
WordDelimiterGraphFilterFactory and SynonymGraphFilterFactory* New
DataImportHandler 'atom' example, replacing broken 'rss' example*
Redone DataImportHandler 'tika' example, removing all unused and
irrelevant definitionsMetrics:* Expose cache statistics using metrics
API* Improvements to metric reporters and API: support for "regex"
parameter in /admin/metrics, "enabled" flag in reporter
configurations, correct handling of "serviceUrl" in SolrJmxReporter,
better handling of service clients for JMX, Ganglia and Graphite
reportersUpgrades/deprecations/removals:* Upgraded Metrics library to
3.2.2, Zookeeper to 3.4.10* Deprecated LatLonType, GeoHashField,
SpatialPointVectorFieldType, and SpatialTermQueryPrefixTreeFieldType.
Instead, switch to LatLonPointSpatialField or
SpatialRecursivePrefixTreeFieldType or RptWithGeometrySpatialField*
Deprecated PostingsSolrHighlighter. Use UnifiedSolrHighlighter
instead.* Removed Solr contribs: map-reduce, morphlines-core and
morphlines-cellSolrJ:* CloudSolrClient can now be initialized using
the base URL of a Solr instance instead of ZooKeeper hosts* SolrJ:
Added SolrParams.toLocalParamsString() and
ClientUtils.encodeLocalParamVal* LBHttpSolrClient.doRequest is now
always wrapped in a Mapped Diagnostic Context (MDC)Others:* New
AtomicUpdateProcessor to convert normal update operations to atomic
update operations* totalTermFreq support to TermsComponent* Hide
keystore and truststore passwords from /admin/info/* outputs*
Configurability for thread pool size to recoveryExecutor* Introducing
sort=childfield(field) asc for searching by {!parent}* Transient core
cache is now pluggable* Renamed getSortWithinGroup to
getWithinGroupSort in search.grouping.CommandOptimizations:*
facet.heatmap is now significantly faster when the docset (base query)
matches everything and there are no deleted docs. It is also faster
when the docset matches a small fraction of the index or none* Reduced
heap consumption for filter({!join ... score=...}) * JSON Facet API
now uses hyper-log-log++ for determining the number of buckets when
merging requests from a multi-shard distributed request* Better
ZkStateWriter batching* Using cache for DistributedQueue in case of
single-consumerFurther 

[ANNOUNCE] Apache Lucene 6.6.0 released

[Ishan Chattopadhyaya]

6 June 2017, Apache Lucene™ 6.6.0 available
The Lucene PMC is pleased to announce the release of Apache Lucene 6.6.0.

Apache Lucene is a high-performance, full-featured text search engine
library written entirely in Java. It is a technology suitable for nearly
any application that requires full-text search, especially cross-platform.

This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release
is available for immediate download at:
  http://lucene.apache.org/core/mirrors-core-latest-redir.html

Please read CHANGES.txt for a full list of new features and changes:
  https://lucene.apache.org/core/6_6_0/changes/Changes.html

Lucene 6.6.0 Release Highlights:

New features:
 * A concurrent SortedSet facets implementation

Optimizations:
 * spatial-extras HeatmapFacetCounter will now short-circuit it's work when
Bits.MatchNoBits is passed

Improvements:
 * OfflineSorter now passes the total number of items it will write to
getWriter()
 * Move dictionary for Ukrainian analyzer to external dependency
 * SortedSetDocValuesReaderState now implements Accountable so one can see
how much RAM it is using
 * OfflineSorter can now run concurrently if you pass it an optional
ExecutorService
 * Sorted set facets now use sparse storage when collecting hits, when
appropriate

Other:
 * PostingsHighlighter has been deprecated in favour of the
UnifiedHighlighter

Along with numerous bug fixes.

Further details of changes are available in the change log available at:
http://lucene.apache.org/core/6_6_0/changes/Changes.html

Please report any feedback to the mailing lists
(http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases.  It is possible that the mirror you are using
may not have replicated the release yet.  If that is the case, please
try another mirror.  This also applies to Maven access.

Re: [ANNOUNCE] Apache Solr 6.4.2 released

[Ishan Chattopadhyaya]

Hi Sahil,
I just confirmed, and so did one of my colleagues, that the redirection is
actually taking the user to the 6.4.2's downloads page.
Do you think it could be a case of stale browser cache in your case? Can
you please try with a different browser, or use curl, to confirm?
Thanks,
Ishan

On Wed, Mar 8, 2017 at 11:31 AM, Sahil Agarwal <sahil.agarwa...@gmail.com>
wrote:

> ​FYI, the http://lucene.apache.org/solr/mirrors-solr-latest-redir.html
>  link redirects to http://www.apache.org/dyn/closer.lua/lucene/solr/6.4.1
> and not http://www.apache.org/dyn/closer.lua/lucene/solr/6.4.2​
>
> On 8 March 2017 at 01:00, Ishan Chattopadhyaya <ichattopadhy...@gmail.com>
> wrote:
>
> > 7 March 2017, Apache Solr 6.4.2 available
> >
> > Solr is the popular, blazing fast, open source NoSQL search platform from
> > the Apache Lucene project. Its major features include powerful full-text
> > search, hit highlighting, faceted search and analytics, rich document
> > parsing, geospatial search, extensive REST APIs as well as parallel SQL.
> > Solr is enterprise grade, secure and highly scalable, providing fault
> > tolerant distributed search and indexing, and powers the search and
> > navigation features of many of the world's largest internet sites.
> >
> > Solr 6.4.2 is available for immediate download at:
> >
> >-
> >
> >http://lucene.apache.org/solr/mirrors-solr-latest-redir.html
> >
> > Please read CHANGES.txt for a full list of new features and changes:
> >
> >-
> >
> >https://lucene.apache.org/solr/6_4_2/changes/Changes.html
> >
> > Solr 6.4.2 contains 4 bug fixes since the 6.4.1 release:
> >
> >-
> >
> >Serious performance degradation in Solr 6.4 due to the metrics
> >collection. IndexWriter metrics collection turned off by default,
> > directory
> >level metrics collection completely removed (until a better design is
> >found)
> >-
> >
> >Transaction log replay can hit an NullPointerException due to new
> >Metrics code
> >-
> >
> >NullPointerException in CloudSolrClient when reading stale alias
> >-
> >
> >UnifiedHighlighter and PostingsHighlighter bug in PrefixQuery and
> >TermRangeQuery for multi-byte text
> >
> > Further details of changes are available in the change log available at:
> > http://lucene.apache.org/solr/6_4_2/changes/Changes.html
> >
> > Please report any feedback to the mailing lists (
> > http://lucene.apache.org/solr/discussion.html)
> > Note: The Apache Software Foundation uses an extensive mirroring network
> > for distributing releases. It is possible that the mirror you are using
> may
> > not have replicated the release yet. If that is the case, please try
> > another mirror. This also applies to Maven access.
> >
>

RE: [ANNOUNCE] Apache Solr 6.4.2 released

[Ishan Chattopadhyaya]

Thanks. I'll have a look.

-Original Message-
From: "Sahil Agarwal" <sahil.agarwa...@gmail.com>
Sent: ‎3/‎8/‎2017 11:32 AM
To: "java-user@lucene.apache.org" <java-user@lucene.apache.org>
Subject: Re: [ANNOUNCE] Apache Solr 6.4.2 released

​FYI, the http://lucene.apache.org/solr/mirrors-solr-latest-redir.html
 link redirects to http://www.apache.org/dyn/closer.lua/lucene/solr/6.4.1
and not http://www.apache.org/dyn/closer.lua/lucene/solr/6.4.2​

On 8 March 2017 at 01:00, Ishan Chattopadhyaya <ichattopadhy...@gmail.com>
wrote:

> 7 March 2017, Apache Solr 6.4.2 available
>
> Solr is the popular, blazing fast, open source NoSQL search platform from
> the Apache Lucene project. Its major features include powerful full-text
> search, hit highlighting, faceted search and analytics, rich document
> parsing, geospatial search, extensive REST APIs as well as parallel SQL.
> Solr is enterprise grade, secure and highly scalable, providing fault
> tolerant distributed search and indexing, and powers the search and
> navigation features of many of the world's largest internet sites.
>
> Solr 6.4.2 is available for immediate download at:
>
>-
>
>http://lucene.apache.org/solr/mirrors-solr-latest-redir.html
>
> Please read CHANGES.txt for a full list of new features and changes:
>
>-
>
>https://lucene.apache.org/solr/6_4_2/changes/Changes.html
>
> Solr 6.4.2 contains 4 bug fixes since the 6.4.1 release:
>
>-
>
>Serious performance degradation in Solr 6.4 due to the metrics
>collection. IndexWriter metrics collection turned off by default,
> directory
>level metrics collection completely removed (until a better design is
>found)
>-
>
>Transaction log replay can hit an NullPointerException due to new
>Metrics code
>-
>
>NullPointerException in CloudSolrClient when reading stale alias
>-
>
>UnifiedHighlighter and PostingsHighlighter bug in PrefixQuery and
>TermRangeQuery for multi-byte text
>
> Further details of changes are available in the change log available at:
> http://lucene.apache.org/solr/6_4_2/changes/Changes.html
>
> Please report any feedback to the mailing lists (
> http://lucene.apache.org/solr/discussion.html)
> Note: The Apache Software Foundation uses an extensive mirroring network
> for distributing releases. It is possible that the mirror you are using may
> not have replicated the release yet. If that is the case, please try
> another mirror. This also applies to Maven access.
>

[ANNOUNCE] Apache Solr 6.4.2 released

[Ishan Chattopadhyaya]

7 March 2017, Apache Solr 6.4.2 available

Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search and analytics, rich document
parsing, geospatial search, extensive REST APIs as well as parallel SQL.
Solr is enterprise grade, secure and highly scalable, providing fault
tolerant distributed search and indexing, and powers the search and
navigation features of many of the world's largest internet sites.

Solr 6.4.2 is available for immediate download at:

   -

   http://lucene.apache.org/solr/mirrors-solr-latest-redir.html

Please read CHANGES.txt for a full list of new features and changes:

   -

   https://lucene.apache.org/solr/6_4_2/changes/Changes.html

Solr 6.4.2 contains 4 bug fixes since the 6.4.1 release:

   -

   Serious performance degradation in Solr 6.4 due to the metrics
   collection. IndexWriter metrics collection turned off by default, directory
   level metrics collection completely removed (until a better design is
   found)
   -

   Transaction log replay can hit an NullPointerException due to new
   Metrics code
   -

   NullPointerException in CloudSolrClient when reading stale alias
   -

   UnifiedHighlighter and PostingsHighlighter bug in PrefixQuery and
   TermRangeQuery for multi-byte text

Further details of changes are available in the change log available at:
http://lucene.apache.org/solr/6_4_2/changes/Changes.html

Please report any feedback to the mailing lists (
http://lucene.apache.org/solr/discussion.html)
Note: The Apache Software Foundation uses an extensive mirroring network
for distributing releases. It is possible that the mirror you are using may
not have replicated the release yet. If that is the case, please try
another mirror. This also applies to Maven access.

[ANNOUNCE] Apache Lucene 6.4.2 released

[Ishan Chattopadhyaya]

7 March 2017, Apache Lucene™ 6.4.2 available

The Lucene PMC is pleased to announce the release of Apache Lucene 6.4.2

Apache Lucene is a high-performance, full-featured text search engine library
written entirely in Java. It is a technology suitable for nearly any
application that requires full-text search, especially cross-platform.

This release contains 1 bug fix since the 6.4.1 release:

   -

   CommonGramsQueryFilter was producing a disconnected token graph, messing
   up phrase queries during query parsing

The release is available for immediate download at:

   -

   http://www.apache.org/dyn/closer.lua/lucene/java/6.4.2

Please read CHANGES.txt for a full list of new features and changes:

   -

   https://lucene.apache.org/core/6_4_2/changes/Changes.html

Please report any feedback to the mailing lists (
http://lucene.apache.org/core/discussion.html)

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not
have replicated the release yet. If that is the case, please try another
mirror. This also goes for Maven access.

Re: Possible to cause documents to be contiguous after forceMerge?

[Ishan Chattopadhyaya]

http://shaierera.blogspot.com/2013/04/index-sorting-with-lucene.html

On Wed, Nov 16, 2016 at 11:15 AM, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Can IndexSort help here?
> --
> From: Erick Erickson <erickerick...@gmail.com>
> Sent: ‎11/‎16/‎2016 9:29
> To: java-user <java-user@lucene.apache.org>
> Subject: Re: Possible to cause documents to be contiguous after
> forceMerge?
>
> Well, codecs are pluggable so if you can show that you'd get
> an improvement (however you measure them) and that whatever
> you have in mind wouldn't penalize the general case you could
> submit it as a proposal/patch.
>
> Best,
> Erick
>
> On Tue, Nov 15, 2016 at 6:21 PM, Kevin Burton <bur...@spinn3r.com> wrote:
> > On Tue, Nov 15, 2016 at 6:16 PM, Erick Erickson <erickerick...@gmail.com
> >
> > wrote:
> >
> >> You can make no assumptions about locality in terms of where separate
> >> documents land on disk. I suppose if you have the whole corpus at index
> >> time you
> >> could index these "similar" documents contiguously. T
> >>
> >
> > Wow.. that's shockingly frightening. There are a ton of optimizations if
> > you can trick the underlying content store into performing locality.
> >
> > Not trying to be overly negative so another way to phrase it is that at
> > least there's room for improvement !
> >
> >
> >> My base question is why you'd care about compressing 500G. Disk space
> >> is so cheap that the expense of trying to control this dwarfs any
> >> imaginable
> >> $avings, unless you're talking about a lot of 500G indexes. In other
> words
> >> this seems like an
> >> XY problem, you're asking about compressing when you are really
> concerned
> >> with something else.
> >>
> >
> > 500GB per day... additionally, disk is cheap, but IOPS are not. The more
> we
> > can keep in ram and on SSD the better.
> >
> > And we're trying to get as much in RAM then SSD as possible... plus we
> have
> > about 2 years of content.  It adds up ;)
> >
> > Kevin
> >
> > --
> >
> > We’re hiring if you know of any awesome Java Devops or Linux Operations
> > Engineers!
> >
> > Founder/CEO Spinn3r.com
> > Location: *San Francisco, CA*
> > blog: http://burtonator.wordpress.com
> > … or check out my Google+ profile
> > <https://plus.google.com/102718274791889610666/posts>
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>

RE: Possible to cause documents to be contiguous after forceMerge?

[Ishan Chattopadhyaya]

Can IndexSort help here?

-Original Message-
From: "Erick Erickson" 
Sent: ‎11/‎16/‎2016 9:29
To: "java-user" 
Subject: Re: Possible to cause documents to be contiguous after forceMerge?

Well, codecs are pluggable so if you can show that you'd get
an improvement (however you measure them) and that whatever
you have in mind wouldn't penalize the general case you could
submit it as a proposal/patch.

Best,
Erick

On Tue, Nov 15, 2016 at 6:21 PM, Kevin Burton  wrote:
> On Tue, Nov 15, 2016 at 6:16 PM, Erick Erickson 
> wrote:
>
>> You can make no assumptions about locality in terms of where separate
>> documents land on disk. I suppose if you have the whole corpus at index
>> time you
>> could index these "similar" documents contiguously. T
>>
>
> Wow.. that's shockingly frightening. There are a ton of optimizations if
> you can trick the underlying content store into performing locality.
>
> Not trying to be overly negative so another way to phrase it is that at
> least there's room for improvement !
>
>
>> My base question is why you'd care about compressing 500G. Disk space
>> is so cheap that the expense of trying to control this dwarfs any
>> imaginable
>> $avings, unless you're talking about a lot of 500G indexes. In other words
>> this seems like an
>> XY problem, you're asking about compressing when you are really concerned
>> with something else.
>>
>
> 500GB per day... additionally, disk is cheap, but IOPS are not. The more we
> can keep in ram and on SSD the better.
>
> And we're trying to get as much in RAM then SSD as possible... plus we have
> about 2 years of content.  It adds up ;)
>
> Kevin
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 

-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org

Obtain list of indexed fields from IndexWriter

[Ishan Chattopadhyaya]

Hi,
If an update to a non-existent dv field is attempted, IndexWriter throws an
exception:
"can only update existing numeric-docvalues fields!".

This exception is thrown after checking with the globalFieldNumberMap
(which is obtained from the SegmentInfos).

Is there a way, given an IndexWriter instance, I can obtain a list of
fields that have been indexed through this writer (so that I can check
before attempting to update a non-existing DV field)? In absence of
something that I'm missing that exists already, is it possible to expose
either the segmentInfos or the globalFieldNumberMap as a public API?

Regards,
Ishan

Re: Lucene indexing throughput (and Mike's lucenebench charts)

[Ishan Chattopadhyaya]

Wow, 72 cores? That sounds astounding. Are they dual Xeon E5 2699 v3 CPUs
with 18 cores each, with hyperthreading = 18*2*2=72 threads?

On Thu, Apr 14, 2016 at 11:33 PM, Dawid Weiss  wrote:

> The GC change is after this:
>
> BJ (2015-12-02): Upgrade to beast2 (72 cores, 256 GB RAM)
>
> which leads me to believe these results are not comparable (different
> machines, architectures, disks, CPUs perhaps?).
>
> Dawid
>
>
> On Thu, Apr 14, 2016 at 7:13 PM, Otis Gospodnetić
>  wrote:
> > Hi,
> >
> > I was looking at Mike's
> > http://home.apache.org/~mikemccand/lucenebench/indexing.html secretly
> > hoping to spot some recent improvements in indexing throughput but
> > instead it looks like:
> >
> > * indexing throughput hasn't really gone up in the last ~5 years
> > * indexing was faster in 2014, but then dropped to pre-2014 speed in
> early
> > 2015
> > * indexing rate dropped some more in early 2016, and that seems to
> roughly
> > correlate to a *big* jump in Young GC in late 2015
> >
> > Does anyone know what happened in late 2015 that causes that big Young GC
> > jump?
> > Or does that big jump just look scary in that chart, but is not actually
> a
> > big concern in practice?
> >
> > Thanks,
> > Otis
> > --
> > Monitoring - Log Management - Alerting - Anomaly Detection
> > Solr & Elasticsearch Consulting Support Training - http://sematext.com/
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>

Re: Jira issue for possibly transient resource issue, or a Lucene or JVM bug?

[Ishan Chattopadhyaya]

LUCENE-6970

On Thu, Jan 21, 2016 at 4:07 PM, Markus Jelsma 
wrote:

> Hi - we get the above issue as well some times. I've noticed Lucene-dev
> mails on this issue [1] but i couldn't find a corresponding Jira issue? Any
> pointer to that one?
>
> Many thanks,
> Markus
>
> [1]
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201601.mbox/%3CCAPsWd+OWZpRLXCyXsvhjufvouM=haavxupj7gkesha4h3jj...@mail.gmail.com%3E
>
> -
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
>
>

Term query equivalent in Dimensional fields?

[Ishan Chattopadhyaya]

Hi, (Mike?)
I am exploring Dimensional fields and excited about the potential speedups
and improved efficiency.

I have a DimensionalIntField (one dimensional) indexed, and wish to do
something equivalent to a Term query for a particular value. Is the
following the best way?

I want to do: new Term("myfield", "1");

I'm trying: DimensionalRangeQuery.new1DIntRange(fname, 1, true, 1, true);

Thanks,
Ishan