date:20131112

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820083#comment-13820083
 ] 

Robert Muir commented on LUCENE-2899:
-

I don't think we should expand the analysis protocol: I think its actually 
already more complicated than it needs to be.

It doesnt need to work across multiple fields or support things like NER.

I know people disagree, but i dont care (typically they dont do a lot of work 
to maintain this code). 

I'll fight it to the death: Lucene's analysis is about doing information 
retrieval (search and query), and its already overly complex. It should stay 
per-field, it should stay like a state machine it is.

Stuff like this NER should *NOT* be in the analysis chain. as i said, its more 
useful in the document build phase anyway.

 Add OpenNLP Analysis capabilities as a module
 -

 Key: LUCENE-2899
 URL: https://issues.apache.org/jira/browse/LUCENE-2899
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 4.6

 Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, 
 OpenNLPFilter.java, OpenNLPTokenizer.java


 Now that OpenNLP is an ASF project and has a nice license, it would be nice 
 to have a submodule (under analysis) that exposed capabilities for it. Drew 
 Farris, Tom Morton and I have code that does:
 * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
 would have to change slightly to buffer tokens)
 * NamedEntity recognition as a TokenFilter
 We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
 either payloads (PartOfSpeechAttribute?) on a token or at the same position.
 I'd propose it go under:
 modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

2013-11-12 Thread Benson Margulies (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820085#comment-13820085
 ] 

Benson Margulies commented on LUCENE-2899:
--

Fair enough. Solr URP's do this very well upstream of analysis. ES doesn't have 
the concept, perhaps it should. It clarifies the situation nicely to think of 
Lucene as serial token operations.

 Add OpenNLP Analysis capabilities as a module
 -

 Key: LUCENE-2899
 URL: https://issues.apache.org/jira/browse/LUCENE-2899
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 4.6

 Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, 
 OpenNLPFilter.java, OpenNLPTokenizer.java


 Now that OpenNLP is an ASF project and has a nice license, it would be nice 
 to have a submodule (under analysis) that exposed capabilities for it. Drew 
 Farris, Tom Morton and I have code that does:
 * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
 would have to change slightly to buffer tokens)
 * NamedEntity recognition as a TokenFilter
 We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
 either payloads (PartOfSpeechAttribute?) on a token or at the same position.
 I'd propose it go under:
 modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.

2013-11-12 Thread Adrien Grand (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820091#comment-13820091
 ] 

Adrien Grand commented on LUCENE-5336:
--

Javadocs and code seem to disagree on the default operator: javadocs say {{The 
default operator is AND if no other operator is specified.}} while the code has 
{{private BooleanClause.Occur defaultOperator = BooleanClause.Occur.SHOULD;}}?

Otherwise I agree with Mike that this new query parser is awesome. I will 
certainly use it!

 Add a simple QueryParser to parse human-entered queries.
 

 Key: LUCENE-5336
 URL: https://issues.apache.org/jira/browse/LUCENE-5336
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Jack Conradson
 Attachments: LUCENE-5336.patch, LUCENE-5336.patch


 I would like to add a new simple QueryParser to Lucene that is designed to 
 parse human-entered queries.  This parser will operate on an entire entered 
 query using a specified single field or a set of weighted fields (using term 
 boost).
 All features/operations in this parser can be enabled or disabled depending 
 on what is necessary for the user.  A default operator may be specified as 
 either 'MUST' representing 'and' or 'SHOULD' representing 'or.'  The 
 features/operations that this parser will include are the following:
 * AND specified as '+'
 * OR specified as '|'
 * NOT specified as '-'
 * PHRASE surrounded by double quotes
 * PREFIX specified as '*'
 * PRECEDENCE surrounded by '(' and ')'
 * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default 
 operator to be used
 * ESCAPE specified as '\' will allow operators to be used in terms
 The key differences between this parser and other existing parsers will be 
 the following:
 * No exceptions will be thrown, and errors in syntax will be ignored.  The 
 parser will do a best-effort interpretation of any query entered.
 * It uses minimal syntax to express queries.  All available operators are 
 single characters or pairs of single characters.
 * The parser is hand-written and in a single Java file making it easy to 
 modify.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

2013-11-12 Thread Christian Moen (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820093#comment-13820093
 ] 

Christian Moen commented on LUCENE-2899:


bq. Stuff like this NER should NOT be in the analysis chain. as i said, its 
more useful in the document build phase anyway.

+1

Benson, as far as I understand, ES doesn't have the concept by design.

 Add OpenNLP Analysis capabilities as a module
 -

 Key: LUCENE-2899
 URL: https://issues.apache.org/jira/browse/LUCENE-2899
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 4.6

 Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, 
 OpenNLPFilter.java, OpenNLPTokenizer.java


 Now that OpenNLP is an ASF project and has a nice license, it would be nice 
 to have a submodule (under analysis) that exposed capabilities for it. Drew 
 Farris, Tom Morton and I have code that does:
 * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
 would have to change slightly to buffer tokens)
 * NamedEntity recognition as a TokenFilter
 We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
 either payloads (PartOfSpeechAttribute?) on a token or at the same position.
 I'd propose it go under:
 modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5301) All PackedInts APIs should share a common interface for random-access reads


[ 
https://issues.apache.org/jira/browse/LUCENE-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820099#comment-13820099
 ] 

ASF subversion and git services commented on LUCENE-5301:
-

Commit 1541063 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1541063 ]

LUCENE-5301: Add a common interface to PackedInts data-structures, which 
extends NumericDocValues.

 All PackedInts APIs should share a common interface for random-access reads
 ---

 Key: LUCENE-5301
 URL: https://issues.apache.org/jira/browse/LUCENE-5301
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Attachments: LUCENE-5301.patch, LUCENE-5301.patch


 It would be convenient if all PackedInts had a super-class with the {{long 
 get(long index)}} method. Maybe this super-class could even be 
 NumericDocValues so that doc values formats don't need to wrap eg. 
 BlockPackedReader into this kind of construct:
 {code}
 final BlockPackedReader reader = new BlockPackedReader(data, 
 entry.packedIntsVersion, entry.blockSize, entry.count, true);
 return new LongNumericDocValues() {
   @Override
   public long get(long id) {
 return reader.get(id);
   }
 };
 {code}
 Instead, they could just
 {code}
 return new BlockPackedReader(data, entry.packedIntsVersion, 
 entry.blockSize, entry.count, true);
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Resolved] (LUCENE-5301) All PackedInts APIs should share a common interface for random-access reads

2013-11-12 Thread Adrien Grand (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand resolved LUCENE-5301.
--

   Resolution: Fixed
Fix Version/s: 4.6

 All PackedInts APIs should share a common interface for random-access reads
 ---

 Key: LUCENE-5301
 URL: https://issues.apache.org/jira/browse/LUCENE-5301
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.6

 Attachments: LUCENE-5301.patch, LUCENE-5301.patch


 It would be convenient if all PackedInts had a super-class with the {{long 
 get(long index)}} method. Maybe this super-class could even be 
 NumericDocValues so that doc values formats don't need to wrap eg. 
 BlockPackedReader into this kind of construct:
 {code}
 final BlockPackedReader reader = new BlockPackedReader(data, 
 entry.packedIntsVersion, entry.blockSize, entry.count, true);
 return new LongNumericDocValues() {
   @Override
   public long get(long id) {
 return reader.get(id);
   }
 };
 {code}
 Instead, they could just
 {code}
 return new BlockPackedReader(data, entry.packedIntsVersion, 
 entry.blockSize, entry.count, true);
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5301) All PackedInts APIs should share a common interface for random-access reads

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820106#comment-13820106
 ] 

ASF subversion and git services commented on LUCENE-5301:
-

Commit 1541064 from [~jpountz] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1541064 ]

LUCENE-5301: Add a common interface to PackedInts data-structures, which 
extends NumericDocValues.

 All PackedInts APIs should share a common interface for random-access reads
 ---

 Key: LUCENE-5301
 URL: https://issues.apache.org/jira/browse/LUCENE-5301
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.6

 Attachments: LUCENE-5301.patch, LUCENE-5301.patch


 It would be convenient if all PackedInts had a super-class with the {{long 
 get(long index)}} method. Maybe this super-class could even be 
 NumericDocValues so that doc values formats don't need to wrap eg. 
 BlockPackedReader into this kind of construct:
 {code}
 final BlockPackedReader reader = new BlockPackedReader(data, 
 entry.packedIntsVersion, entry.blockSize, entry.count, true);
 return new LongNumericDocValues() {
   @Override
   public long get(long id) {
 return reader.get(id);
   }
 };
 {code}
 Instead, they could just
 {code}
 return new BlockPackedReader(data, entry.packedIntsVersion, 
 entry.blockSize, entry.count, true);
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module

2013-11-12 Thread Joern Kottmann (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820115#comment-13820115
 ] 

Joern Kottmann commented on LUCENE-2899:


UIMA based NLP pipelines can use components like Solrcas or Lucas to write 
their results to an index. This works really well in my experience.

 Add OpenNLP Analysis capabilities as a module
 -

 Key: LUCENE-2899
 URL: https://issues.apache.org/jira/browse/LUCENE-2899
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 4.6

 Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, 
 OpenNLPFilter.java, OpenNLPTokenizer.java


 Now that OpenNLP is an ASF project and has a nice license, it would be nice 
 to have a submodule (under analysis) that exposed capabilities for it. Drew 
 Farris, Tom Morton and I have code that does:
 * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
 would have to change slightly to buffer tokens)
 * NamedEntity recognition as a TokenFilter
 We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
 either payloads (PartOfSpeechAttribute?) on a token or at the same position.
 I'd propose it go under:
 modules/analysis/opennlp



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: Lucene / Solr 4.6

2013-11-12 Thread Simon Willnauer

FYI I just started a release branch http://svn.apache.org/r1541081

On Thu, Nov 7, 2013 at 2:01 PM, Simon Willnauer
simon.willna...@gmail.com wrote:
 Mark, I can do the release if you are busy or so I don't mind lemme
 know if you wanna do it

 simon

 On Thu, Nov 7, 2013 at 1:09 PM, Mark Miller markrmil...@gmail.com wrote:
 Next Tuesday sounds good to me.


 On Thu, Nov 7, 2013 at 9:06 AM, Simon Willnauer simon.willna...@gmail.com
 wrote:

 hey folks,

 I think it's time to get this going. Mark I can do the release as well
 do we wanna set a date? IMO I'd love to start tomorrow but I guess I
 will get some I wanna get featrue XYZ in emails so what about
 cutting the RC next week Tuesday?

 simon

 On Fri, Oct 25, 2013 at 5:22 AM, Otis Gospodnetic
 otis.gospodne...@gmail.com wrote:
  Awesome, if you ask me. I want to try a number of new changes.
 
  Otis
  Solr  ElasticSearch Support
  http://sematext.com/
 
  On Oct 24, 2013 10:14 AM, Mark Miller markrmil...@gmail.com wrote:
 
  I think releasing once a month when we can is great - putting features
  into users hands faster is a dream come true :) Glad we even have the
  option
  now. We have had that cadence breifly before, and when we don’t, it’s
  usually just a lack of a volunteer.
 
  Personally, I want to get out some changes that I’ve worked on.
 
  I love release often. The stuff that doesn’t make it in will come in
  4.7,
  which can also be not long after 4.6.
 
  I just also like a little warning first.
 
  - Mark
 
  On Oct 24, 2013, at 10:03 AM, Shai Erera ser...@gmail.com wrote:
 
  Is there any reason to rush? We've released 4.5.0 just 3 weeks ago.
 
  Shai
 
 
  On Thu, Oct 24, 2013 at 4:54 PM, Adrien Grand jpou...@gmail.com
  wrote:
 
  +1
 
  --
  Adrien
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 

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




 --
 - Mark

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

[jira] [Updated] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.

2013-11-12 Thread ASF subversion and git services (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Muir updated LUCENE-5336:

Attachment: LUCENE-5336.patch

I took a swipe at trying to make the javadocs easier to read (just different
layout).

Also folded in Adrien's fix.

Add a simple QueryParser to parse human-entered queries.

Key: LUCENE-5336
URL: https://issues.apache.org/jira/browse/LUCENE-5336
Project: Lucene - Core
Issue Type: Improvement
Reporter: Jack Conradson
Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch

I would like to add a new simple QueryParser to Lucene that is designed to
parse human-entered queries. This parser will operate on an entire entered
query using a specified single field or a set of weighted fields (using term
boost).
All features/operations in this parser can be enabled or disabled depending
on what is necessary for the user. A default operator may be specified as
either 'MUST' representing 'and' or 'SHOULD' representing 'or.' The
features/operations that this parser will include are the following:
* AND specified as '+'
* OR specified as '|'
* NOT specified as '-'
* PHRASE surrounded by double quotes
* PREFIX specified as '*'
* PRECEDENCE surrounded by '(' and ')'
* WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default
operator to be used
* ESCAPE specified as '\' will allow operators to be used in terms
The key differences between this parser and other existing parsers will be
the following:
* No exceptions will be thrown, and errors in syntax will be ignored. The
parser will do a best-effort interpretation of any query entered.
* It uses minimal syntax to express queries. All available operators are
single characters or pairs of single characters.
* The parser is hand-written and in a single Java file making it easy to
modify.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5428) new statistics results to StatsComponent - distinctValues and countDistinct

2013-11-12 Thread Yago Riveiro (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820159#comment-13820159
 ] 

Yago Riveiro commented on SOLR-5428:


This patch works in distribute queries?

 new statistics results to StatsComponent - distinctValues and countDistinct
 ---

 Key: SOLR-5428
 URL: https://issues.apache.org/jira/browse/SOLR-5428
 Project: Solr
  Issue Type: New Feature
Reporter: Elran Dvir
 Attachments: SOLR-5428.patch


 I thought it would be very useful to display the distinct values (and the 
 count) of a field among other statistics. Attached a patch implementing this 
 in StatsComponent.
 Added results  :
 distinctValues - list of all distnict values
 countDistinct -  distnict values count.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: Lucene / Solr 4.6

2013-11-12 Thread Steve Rowe

Simon,

A few days ago Dawid Weiss upgraded the randomized-testing and junit4-ant 
dependencies in the Ant build, but not in the Maven build, and as a result 
validate-maven-dependencies is failing now on branch_4x - I can’t get to the 
build log for the Jenkins run this showed up on, yesterday I think: the site 
keeps giving me Proxy Error pages when I try to look.

Anyway, I’ll commit a fix shortly - please hold off building an RC until I do.

Also, FYI, I don’t plan on committing LUCENE-5217 and LUCENE-5322 (which draw 
dependencies and their versions from the Ant build, and streamline 
Maven-related Ant build targets, respectively) to the 4.6 release branch - I 
plan on committing tbem later today to branch_4x only.

Steve

On Nov 12, 2013, at 9:32 AM, Simon Willnauer simon.willna...@gmail.com wrote:

 FYI I just started a release branch http://svn.apache.org/r1541081
 
 On Thu, Nov 7, 2013 at 2:01 PM, Simon Willnauer
 simon.willna...@gmail.com wrote:
 Mark, I can do the release if you are busy or so I don't mind lemme
 know if you wanna do it
 
 simon
 
 On Thu, Nov 7, 2013 at 1:09 PM, Mark Miller markrmil...@gmail.com wrote:
 Next Tuesday sounds good to me.
 
 
 On Thu, Nov 7, 2013 at 9:06 AM, Simon Willnauer simon.willna...@gmail.com
 wrote:
 
 hey folks,
 
 I think it's time to get this going. Mark I can do the release as well
 do we wanna set a date? IMO I'd love to start tomorrow but I guess I
 will get some I wanna get featrue XYZ in emails so what about
 cutting the RC next week Tuesday?
 
 simon
 
 On Fri, Oct 25, 2013 at 5:22 AM, Otis Gospodnetic
 otis.gospodne...@gmail.com wrote:
 Awesome, if you ask me. I want to try a number of new changes.
 
 Otis
 Solr  ElasticSearch Support
 http://sematext.com/
 
 On Oct 24, 2013 10:14 AM, Mark Miller markrmil...@gmail.com wrote:
 
 I think releasing once a month when we can is great - putting features
 into users hands faster is a dream come true :) Glad we even have the
 option
 now. We have had that cadence breifly before, and when we don’t, it’s
 usually just a lack of a volunteer.
 
 Personally, I want to get out some changes that I’ve worked on.
 
 I love release often. The stuff that doesn’t make it in will come in
 4.7,
 which can also be not long after 4.6.
 
 I just also like a little warning first.
 
 - Mark
 
 On Oct 24, 2013, at 10:03 AM, Shai Erera ser...@gmail.com wrote:
 
 Is there any reason to rush? We've released 4.5.0 just 3 weeks ago.
 
 Shai
 
 
 On Thu, Oct 24, 2013 at 4:54 PM, Adrien Grand jpou...@gmail.com
 wrote:
 
 +1
 
 --
 Adrien
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 
 --
 - Mark
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


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

[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.

2013-11-12 Thread Michael McCandless (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820196#comment-13820196
 ] 

Michael McCandless commented on LUCENE-5336:


+1, javadocs and the new test look great!

 Add a simple QueryParser to parse human-entered queries.
 

 Key: LUCENE-5336
 URL: https://issues.apache.org/jira/browse/LUCENE-5336
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Jack Conradson
 Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch


 I would like to add a new simple QueryParser to Lucene that is designed to 
 parse human-entered queries.  This parser will operate on an entire entered 
 query using a specified single field or a set of weighted fields (using term 
 boost).
 All features/operations in this parser can be enabled or disabled depending 
 on what is necessary for the user.  A default operator may be specified as 
 either 'MUST' representing 'and' or 'SHOULD' representing 'or.'  The 
 features/operations that this parser will include are the following:
 * AND specified as '+'
 * OR specified as '|'
 * NOT specified as '-'
 * PHRASE surrounded by double quotes
 * PREFIX specified as '*'
 * PRECEDENCE surrounded by '(' and ')'
 * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default 
 operator to be used
 * ESCAPE specified as '\' will allow operators to be used in terms
 The key differences between this parser and other existing parsers will be 
 the following:
 * No exceptions will be thrown, and errors in syntax will be ignored.  The 
 parser will do a best-effort interpretation of any query entered.
 * It uses minimal syntax to express queries.  All available operators are 
 single characters or pairs of single characters.
 * The parser is hand-written and in a single Java file making it easy to 
 modify.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-4852) If sharedLib is set to lib, classloader fails to find classes in lib

2013-11-12 Thread Shawn Heisey (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820197#comment-13820197
]

Shawn Heisey commented on SOLR-4852:

There may be some confusion about what's going on with this issue.

This issue affects 4.3 and later. Summary: If you are putting jars in
solrhome/lib then you must remove any sharedLib setting that points at this
directory, either with lib or an explicit path. Also, you cannot put some
jars in solrhome/lib and others in a location specified by sharedLib - they
must all be in the same location.

The same config won't work on 4.2.1 and earlier if you are putting jars in
solrhome/lib. The sharedLib attribute must exist and point at that location,
or you will see that the classloader loads the jars, but the classes in those
jars are not found when the config or schema tries to use them. This part is
something I learned today while trying to work with the older version.

If sharedLib is set to lib, classloader fails to find classes in lib

Key: SOLR-4852
URL: https://issues.apache.org/jira/browse/SOLR-4852
Project: Solr
Issue Type: Bug
Affects Versions: 4.4
Environment: Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1
SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
java version 1.7.0_21
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
Reporter: Shawn Heisey
Fix For: 4.6

Attachments: SOLR-4852-test-failhard.txt, SOLR-4852.patch,
SOLR-4852.patch

I have some jars in the lib directory under solr.solr.home - DIH, ICU, and
MySQL. If I set sharedLib in solr.xml to lib then the ICUTokenizer class
is not found, even though the jar is loaded (twice) during Solr startup. If
I set sharedLib to another location that doesn't exist, the jars are only
loaded once and there is no problem.
I'm using the old-style solr.xml on branch_4x revision 1485566.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Comment Edited] (SOLR-4852) If sharedLib is set to lib, classloader fails to find classes in lib

2013-11-12 Thread Shawn Heisey (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820197#comment-13820197
]

Shawn Heisey edited comment on SOLR-4852 at 11/12/13 3:41 PM:
--

There may be some confusion about what's going on with this issue.

I've been told that the behavior documented in this issue is not actually a
problem. I personally disagree with that assessment, but there is a workaround
available. We probably need some minor documentation changes.

was (Author: elyograg):
There may be some confusion about what's going on with this issue.

If sharedLib is set to lib, classloader fails to find classes in lib

Attachments: SOLR-4852-test-failhard.txt, SOLR-4852.patch,
SOLR-4852.patch

--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).


[ 
https://issues.apache.org/jira/browse/LUCENE-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820202#comment-13820202
 ] 

ASF subversion and git services commented on LUCENE-5283:
-

Commit 1541116 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1541116 ]

LUCENE-5283: Maven config

 Fail the build if ant test didn't execute any tests (everything filtered out).
 --

 Key: LUCENE-5283
 URL: https://issues.apache.org/jira/browse/LUCENE-5283
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Fix For: 4.6, 5.0

 Attachments: LUCENE-5283-permgen.patch, LUCENE-5283.patch, 
 LUCENE-5283.patch, LUCENE-5283.patch


 This should be an optional setting that defaults to 'false' (the build 
 proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820204#comment-13820204
 ] 

ASF subversion and git services commented on LUCENE-5283:
-

Commit 1541117 from [~steve_rowe] in branch 'dev/branches/lucene_solr_4_6'
[ https://svn.apache.org/r1541117 ]

LUCENE-5283: Maven config (merged branch_4x r1541116)

 Fail the build if ant test didn't execute any tests (everything filtered out).
 --

 Key: LUCENE-5283
 URL: https://issues.apache.org/jira/browse/LUCENE-5283
 Project: Lucene - Core
  Issue Type: Wish
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
 Fix For: 4.6, 5.0

 Attachments: LUCENE-5283-permgen.patch, LUCENE-5283.patch, 
 LUCENE-5283.patch, LUCENE-5283.patch


 This should be an optional setting that defaults to 'false' (the build 
 proceeds).



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-4260) Inconsistent numDocs between leader and replica

2013-11-12 Thread Markus Jelsma (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820205#comment-13820205
]

Markus Jelsma commented on SOLR-4260:
-

I can confirm as well that is issue still exists. Since yesterday one of a
shard's replica has one document less than it should have. Solr doesn't notice
this and makes no attempt in recovering this issue. Around the time when i
noticed it first we were shutting down and restarting nodes, it's likely that
at that time some documents got indexed as well.

Inconsistent numDocs between leader and replica
---

Key: SOLR-4260
URL: https://issues.apache.org/jira/browse/SOLR-4260
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 5.0
Environment: 5.0.0.2013.01.04.15.31.51
Reporter: Markus Jelsma
Priority: Critical
Fix For: 5.0

Attachments: 192.168.20.102-replica1.png,
192.168.20.104-replica2.png, clusterstate.png

After wiping all cores and reindexing some 3.3 million docs from Nutch using
CloudSolrServer we see inconsistencies between the leader and replica for
some shards.
Each core hold about 3.3k documents. For some reason 5 out of 10 shards have
a small deviation in then number of documents. The leader and slave deviate
for roughly 10-20 documents, not more.
Results hopping ranks in the result set for identical queries got my
attention, there were small IDF differences for exactly the same record
causing a record to shift positions in the result set. During those tests no
records were indexed. Consecutive catch all queries also return different
number of numDocs.
We're running a 10 node test cluster with 10 shards and a replication factor
of two and frequently reindex using a fresh build from trunk. I've not seen
this issue for quite some time until a few days ago.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: Lucene / Solr 4.6

2013-11-12 Thread Steve Rowe

I upgraded the randomized-testing dependency in the Maven build on branch_4x 
and lucene_solr_4_6 (4.6 branch: r1541117).  

(The junit4-ant dependency isn’t used by the Maven build, so nothing needed to 
change for it.)

‘ant validate-maven-dependencies' failed locally for me before this change, and 
succeeded afterward.

Sorry for the disruption, Simon, please go ahead with building the RC.

Steve

On Nov 12, 2013, at 10:33 AM, Steve Rowe sar...@gmail.com wrote:

 Simon,
 
 A few days ago Dawid Weiss upgraded the randomized-testing and junit4-ant 
 dependencies in the Ant build, but not in the Maven build, and as a result 
 validate-maven-dependencies is failing now on branch_4x - I can’t get to the 
 build log for the Jenkins run this showed up on, yesterday I think: the site 
 keeps giving me Proxy Error pages when I try to look.
 
 Anyway, I’ll commit a fix shortly - please hold off building an RC until I do.
 
 Also, FYI, I don’t plan on committing LUCENE-5217 and LUCENE-5322 (which draw 
 dependencies and their versions from the Ant build, and streamline 
 Maven-related Ant build targets, respectively) to the 4.6 release branch - I 
 plan on committing tbem later today to branch_4x only.
 
 Steve
 
 On Nov 12, 2013, at 9:32 AM, Simon Willnauer simon.willna...@gmail.com 
 wrote:
 
 FYI I just started a release branch http://svn.apache.org/r1541081
 
 On Thu, Nov 7, 2013 at 2:01 PM, Simon Willnauer
 simon.willna...@gmail.com wrote:
 Mark, I can do the release if you are busy or so I don't mind lemme
 know if you wanna do it
 
 simon
 
 On Thu, Nov 7, 2013 at 1:09 PM, Mark Miller markrmil...@gmail.com wrote:
 Next Tuesday sounds good to me.
 
 
 On Thu, Nov 7, 2013 at 9:06 AM, Simon Willnauer simon.willna...@gmail.com
 wrote:
 
 hey folks,
 
 I think it's time to get this going. Mark I can do the release as well
 do we wanna set a date? IMO I'd love to start tomorrow but I guess I
 will get some I wanna get featrue XYZ in emails so what about
 cutting the RC next week Tuesday?
 
 simon
 
 On Fri, Oct 25, 2013 at 5:22 AM, Otis Gospodnetic
 otis.gospodne...@gmail.com wrote:
 Awesome, if you ask me. I want to try a number of new changes.
 
 Otis
 Solr  ElasticSearch Support
 http://sematext.com/
 
 On Oct 24, 2013 10:14 AM, Mark Miller markrmil...@gmail.com wrote:
 
 I think releasing once a month when we can is great - putting features
 into users hands faster is a dream come true :) Glad we even have the
 option
 now. We have had that cadence breifly before, and when we don’t, it’s
 usually just a lack of a volunteer.
 
 Personally, I want to get out some changes that I’ve worked on.
 
 I love release often. The stuff that doesn’t make it in will come in
 4.7,
 which can also be not long after 4.6.
 
 I just also like a little warning first.
 
 - Mark
 
 On Oct 24, 2013, at 10:03 AM, Shai Erera ser...@gmail.com wrote:
 
 Is there any reason to rush? We've released 4.5.0 just 3 weeks ago.
 
 Shai
 
 
 On Thu, Oct 24, 2013 at 4:54 PM, Adrien Grand jpou...@gmail.com
 wrote:
 
 +1
 
 --
 Adrien
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 
 --
 - Mark
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 


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

[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.

2013-11-12 Thread Adrien Grand (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820218#comment-13820218
 ] 

Adrien Grand commented on LUCENE-5336:
--

+1

 Add a simple QueryParser to parse human-entered queries.
 

 Key: LUCENE-5336
 URL: https://issues.apache.org/jira/browse/LUCENE-5336
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Jack Conradson
 Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch


 I would like to add a new simple QueryParser to Lucene that is designed to 
 parse human-entered queries.  This parser will operate on an entire entered 
 query using a specified single field or a set of weighted fields (using term 
 boost).
 All features/operations in this parser can be enabled or disabled depending 
 on what is necessary for the user.  A default operator may be specified as 
 either 'MUST' representing 'and' or 'SHOULD' representing 'or.'  The 
 features/operations that this parser will include are the following:
 * AND specified as '+'
 * OR specified as '|'
 * NOT specified as '-'
 * PHRASE surrounded by double quotes
 * PREFIX specified as '*'
 * PRECEDENCE surrounded by '(' and ')'
 * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default 
 operator to be used
 * ESCAPE specified as '\' will allow operators to be used in terms
 The key differences between this parser and other existing parsers will be 
 the following:
 * No exceptions will be thrown, and errors in syntax will be ignored.  The 
 parser will do a best-effort interpretation of any query entered.
 * It uses minimal syntax to express queries.  All available operators are 
 single characters or pairs of single characters.
 * The parser is hand-written and in a single Java file making it easy to 
 modify.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: Lucene / Solr 4.6

2013-11-12 Thread Dawid Weiss

 A few days ago Dawid Weiss upgraded the randomized-testing and junit4-ant 
 dependencies in the Ant build, but not in the Maven build,

Umm, that's odd, I typically remember about that. [checking]. Yeah --
sorry about that, I merged changes from trunk automatically and didn't
notice that single-props file is not backported to 4x... My apologies
and thanks for fixing this, Steve.

Dawid

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

[jira] [Commented] (SOLR-5436) Eliminate the 1500ms wait in overseer loop

2013-11-12 Thread Noble Paul (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820228#comment-13820228
 ] 

Noble Paul commented on SOLR-5436:
--

[~shalinmangar] Originally we did not have a blocking lookup of the queue. that 
was also one of the reasons. 

 Eliminate the 1500ms wait in overseer loop
 --

 Key: SOLR-5436
 URL: https://issues.apache.org/jira/browse/SOLR-5436
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor

 The Overseer thread waits 1500 ms before it polls for new events. The wait 
 should be eliminated and it should just wait for new events till they come 
 the way it is done in OverseerCollectionProcessor



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: Solr Release Management Process

2013-11-12 Thread Furkan KAMACI

Any ideas about it?


2013/11/11 Furkan KAMACI furkankam...@gmail.com

 Hi;

 I've resolved 2 issues last week. One of them is created by me and one of
 them was an existence issue. Also there is an 3rd issue that is a
 duplication of the second one.

 When I create an issue I have a right to edit Fix Version/s. I've written
 4.6 for fix version of first issue. Second issue was not created by me so I
 can not edit the Fix Version/s.

 I just wonder and want to learn commitment process of Solr project. What
 committers do before a new release process start? If they filter the
 resolved issues that has a Fix Version/s of new release they will not able
 to see resolved issues. If they filter the issues resolved since the last
 release then they are not using the benefits of Fix Version/s section.
 People have a right to edit Fix Version/s section when they create an issue
 but does not have a right to edit existence one (ones are created by other
 people)

 There are many issues at Solr project and frequent commits every day.
 Should I point the user at comments (with an @ tag) for such kind of
 situations (I follow who is responsible for next release from dev-list) or
 do you handle it yourself (as like how you handled it since this time).

 I just wanted to learn the internal process of release management.

 Thanks;
 Furkan KAMACI

[jira] [Created] (SOLR-5437) DeleteReplicaTest fails constantly both locally and in jenkins

2013-11-12 Thread ASF subversion and git services (JIRA)

Robert Muir created SOLR-5437:
-

 Summary: DeleteReplicaTest fails constantly both locally and in 
jenkins
 Key: SOLR-5437
 URL: https://issues.apache.org/jira/browse/SOLR-5437
 Project: Solr
  Issue Type: Bug
Reporter: Robert Muir
 Fix For: 4.6






--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.


[ 
https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820251#comment-13820251
 ] 

ASF subversion and git services commented on LUCENE-5336:
-

Commit 1541151 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1541151 ]

LUCENE-5336: add SimpleQueryParser for human-entered queries

 Add a simple QueryParser to parse human-entered queries.
 

 Key: LUCENE-5336
 URL: https://issues.apache.org/jira/browse/LUCENE-5336
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Jack Conradson
 Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch


 I would like to add a new simple QueryParser to Lucene that is designed to 
 parse human-entered queries.  This parser will operate on an entire entered 
 query using a specified single field or a set of weighted fields (using term 
 boost).
 All features/operations in this parser can be enabled or disabled depending 
 on what is necessary for the user.  A default operator may be specified as 
 either 'MUST' representing 'and' or 'SHOULD' representing 'or.'  The 
 features/operations that this parser will include are the following:
 * AND specified as '+'
 * OR specified as '|'
 * NOT specified as '-'
 * PHRASE surrounded by double quotes
 * PREFIX specified as '*'
 * PRECEDENCE surrounded by '(' and ')'
 * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default 
 operator to be used
 * ESCAPE specified as '\' will allow operators to be used in terms
 The key differences between this parser and other existing parsers will be 
 the following:
 * No exceptions will be thrown, and errors in syntax will be ignored.  The 
 parser will do a best-effort interpretation of any query entered.
 * It uses minimal syntax to express queries.  All available operators are 
 single characters or pairs of single characters.
 * The parser is hand-written and in a single Java file making it easy to 
 modify.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820254#comment-13820254
 ] 

ASF subversion and git services commented on LUCENE-5336:
-

Commit 1541158 from [~rcmuir] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1541158 ]

LUCENE-5336: add SimpleQueryParser for human-entered queries

 Add a simple QueryParser to parse human-entered queries.
 

 Key: LUCENE-5336
 URL: https://issues.apache.org/jira/browse/LUCENE-5336
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Jack Conradson
 Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch


 I would like to add a new simple QueryParser to Lucene that is designed to 
 parse human-entered queries.  This parser will operate on an entire entered 
 query using a specified single field or a set of weighted fields (using term 
 boost).
 All features/operations in this parser can be enabled or disabled depending 
 on what is necessary for the user.  A default operator may be specified as 
 either 'MUST' representing 'and' or 'SHOULD' representing 'or.'  The 
 features/operations that this parser will include are the following:
 * AND specified as '+'
 * OR specified as '|'
 * NOT specified as '-'
 * PHRASE surrounded by double quotes
 * PREFIX specified as '*'
 * PRECEDENCE surrounded by '(' and ')'
 * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default 
 operator to be used
 * ESCAPE specified as '\' will allow operators to be used in terms
 The key differences between this parser and other existing parsers will be 
 the following:
 * No exceptions will be thrown, and errors in syntax will be ignored.  The 
 parser will do a best-effort interpretation of any query entered.
 * It uses minimal syntax to express queries.  All available operators are 
 single characters or pairs of single characters.
 * The parser is hand-written and in a single Java file making it easy to 
 modify.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Resolved] (LUCENE-5336) Add a simple QueryParser to parse human-entered queries.


 [ 
https://issues.apache.org/jira/browse/LUCENE-5336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir resolved LUCENE-5336.
-

   Resolution: Fixed
Fix Version/s: 4.7
   5.0

Thanks Jack!

 Add a simple QueryParser to parse human-entered queries.
 

 Key: LUCENE-5336
 URL: https://issues.apache.org/jira/browse/LUCENE-5336
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Jack Conradson
 Fix For: 5.0, 4.7

 Attachments: LUCENE-5336.patch, LUCENE-5336.patch, LUCENE-5336.patch


 I would like to add a new simple QueryParser to Lucene that is designed to 
 parse human-entered queries.  This parser will operate on an entire entered 
 query using a specified single field or a set of weighted fields (using term 
 boost).
 All features/operations in this parser can be enabled or disabled depending 
 on what is necessary for the user.  A default operator may be specified as 
 either 'MUST' representing 'and' or 'SHOULD' representing 'or.'  The 
 features/operations that this parser will include are the following:
 * AND specified as '+'
 * OR specified as '|'
 * NOT specified as '-'
 * PHRASE surrounded by double quotes
 * PREFIX specified as '*'
 * PRECEDENCE surrounded by '(' and ')'
 * WHITESPACE specified as ' ' '\n' '\r' and '\t' will cause the default 
 operator to be used
 * ESCAPE specified as '\' will allow operators to be used in terms
 The key differences between this parser and other existing parsers will be 
 the following:
 * No exceptions will be thrown, and errors in syntax will be ignored.  The 
 parser will do a best-effort interpretation of any query entered.
 * It uses minimal syntax to express queries.  All available operators are 
 single characters or pairs of single characters.
 * The parser is hand-written and in a single Java file making it easy to 
 modify.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Assigned] (SOLR-5437) DeleteReplicaTest fails constantly both locally and in jenkins

2013-11-12 Thread Shalin Shekhar Mangar (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shalin Shekhar Mangar reassigned SOLR-5437:
---

Assignee: Noble Paul

 DeleteReplicaTest fails constantly both locally and in jenkins
 --

 Key: SOLR-5437
 URL: https://issues.apache.org/jira/browse/SOLR-5437
 Project: Solr
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Noble Paul
 Fix For: 4.6






--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: Adding preserveOriginal Capability to EdgeNGramFilterFactory

2013-11-12 Thread Kranti Parisa

Can EdgeNGramFilterFactory handle the cases where we need to skip/consider
the n words from the start or end?

For example:

Title: big bang theory

field1: populate full ngrams
field2: populate ngrams for bang theory = skipping the first word big
field3: populate ngrams for big = considering only the first word big
field4: populate ngrams for theory = considering only the last word
theory

and at query time, I would like to apply field level boosting to rank the
results.



Thanks,
Kranti K. Parisa
http://www.linkedin.com/in/krantiparisa



On Sun, Nov 10, 2013 at 5:51 PM, Furkan KAMACI furkankam...@gmail.comwrote:

 Hi;

 There were two issues about adding preserveOriginal capability to
 EdgeNGramFilterFactory and I've made a patch about it. You can check and
 test it from here: https://issues.apache.org/jira/browse/SOLR-5152 This
 is the related issue that can be marked as duplicated:
 https://issues.apache.org/jira/browse/SOLR-5332

 Thanks;
 Furkan KAMACI

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820279#comment-13820279
 ] 

Joel Bernstein commented on SOLR-5408:
--

Erick,

I like the a test case. Only one concern and that is the assertion of 5 
segments. Could be a race condition here where a background merge gets done in 
between commits, causing there to be fewer then 5 segments.

I was thinking about just taking out this assertion and using the rest of the 
test. All we need is there to be more then 1 segment to ensure the test is 
valid.

Let me know what you think,

Thanks,
Joel

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: Lucene / Solr 4.6

2013-11-12 Thread Simon Willnauer

FYI I won't be able to kick this off today so I am building an RC tomorrow CEST

On Tue, Nov 12, 2013 at 5:23 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
 A few days ago Dawid Weiss upgraded the randomized-testing and junit4-ant 
 dependencies in the Ant build, but not in the Maven build,

 Umm, that's odd, I typically remember about that. [checking]. Yeah --
 sorry about that, I merged changes from trunk automatically and didn't
 notice that single-props file is not backported to 4x... My apologies
 and thanks for fixing this, Steve.

 Dawid

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820368#comment-13820368
 ] 

Joel Bernstein commented on SOLR-5408:
--

Further testing shows the bug is still present after this patch. Continuing to 
investigate...

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields

2013-11-12 Thread Erik Hatcher (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820397#comment-13820397
 ] 

Erik Hatcher commented on SOLR-5408:


bq.  Only one concern and that is the assertion of 5 segments... All we need is 
there to be more then 1 segment to ensure the test is valid.

+1, by all means modify the test to whatever makes sense here.  Maybe 
{code}assertTrue(Must be more than one segment, 
searcherRef.get().getIndexReader().leaves().size()  1){code} or something like 
that?

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields

2013-11-12 Thread Erik Hatcher (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820400#comment-13820400
 ] 

Erik Hatcher commented on SOLR-5408:


bq. Further testing shows the bug is still present after this patch.

Under what conditions?  Can you post a failing test case?

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820424#comment-13820424
 ] 

Joel Bernstein commented on SOLR-5408:
--

When I started testing with a larger dataset (millions) it become apparent 
pretty quickly that things will still broken with the score sorting when other 
criteria is used.

I'm about to post the fix that worked on the larger data set.

I'll have to give some thought into how get this to break with a small test 
case.

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Comment Edited] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820424#comment-13820424
 ] 

Joel Bernstein edited comment on SOLR-5408 at 11/12/13 8:38 PM:


When I started testing with a larger dataset (millions) it become apparent 
pretty quickly that things were still broken with the score sorting when other 
criteria is used.

I'm about to post the fix that worked on the larger data set.

I'll have to give some thought into how get this to break with a small test 
case.


was (Author: joel.bernstein):
When I started testing with a larger dataset (millions) it become apparent 
pretty quickly that things will still broken with the score sorting when other 
criteria is used.

I'm about to post the fix that worked on the larger data set.

I'll have to give some thought into how get this to break with a small test 
case.

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


 [ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-5408:
-

Attachment: SOLR-5408.2.patch

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820431#comment-13820431
 ] 

Joel Bernstein commented on SOLR-5408:
--

I just posted new patch.

This patch makes a change to the dummy scorer that is passed down to the 
delegate collector.

The issue was that certain priority queue implementations wrap the scorer in a 
cache that saves the score for the last docId. For this cache to work properly 
the dummy scorer needed to implement the docID() method properly. This patch 
does that.

Not all the priority queue implementations use this technique, so depending on 
how the query is executed you may or may not hit the bug.

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Comment Edited] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820431#comment-13820431
 ] 

Joel Bernstein edited comment on SOLR-5408 at 11/12/13 8:45 PM:


I just posted a new patch.

This patch makes a change to the dummy scorer that is passed down to the 
delegate collector.

The issue was that certain priority queue implementations wrap the scorer in a 
cache that saves the score for the last docId. For this cache to work properly 
the dummy scorer needed to implement the docID() method properly. This patch 
does that.

Not all the priority queue implementations use this technique, so depending on 
how the query is executed you may or may not hit the bug.


was (Author: joel.bernstein):
I just posted new patch.

This patch makes a change to the dummy scorer that is passed down to the 
delegate collector.

The issue was that certain priority queue implementations wrap the scorer in a 
cache that saves the score for the last docId. For this cache to work properly 
the dummy scorer needed to implement the docID() method properly. This patch 
does that.

Not all the priority queue implementations use this technique, so depending on 
how the query is executed you may or may not hit the bug.

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820434#comment-13820434
 ] 

Joel Bernstein commented on SOLR-5408:
--

Brandon,

If you want to post your version of the CollapsingQParserPlugin directly to 
this ticket. I will make the changes to the version you have and post it back.

Otherwise, I will shortly be committing this fix to trunk and 4x so you could 
replace your version with the latest version.

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820449#comment-13820449
 ] 

ASF subversion and git services commented on SOLR-5408:
---

Commit 1541232 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1541232 ]

SOLR-5408 Fixed issue with scorer

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields

2013-11-12 Thread Brandon Chapman (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Chapman updated SOLR-5408:
--

Attachment: SOLR-5027.patch

Attached patch that we are using.

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5027.patch, SOLR-5408.2.patch, SOLR-5408.patch, 
 SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820505#comment-13820505
 ] 

Joel Bernstein commented on SOLR-5408:
--

Brandon,

I'll edit your version of the CollapsingQParserPlugin directly and post that 
back to the ticket.

So just attach the CollapserQParserPlugin.java file.

Joel 

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: SOLR-5027.patch, SOLR-5408.2.patch, SOLR-5408.patch, 
 SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields

2013-11-12 Thread Brandon Chapman (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Brandon Chapman updated SOLR-5408:
--

Attachment: CollapsingQParserPlugin.java

attaching java file instead of patch

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: CollapsingQParserPlugin.java, SOLR-5027.patch, 
 SOLR-5408.2.patch, SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5399) Improve DebugComponent for distributed requests

2013-11-12 Thread Ryan Ernst (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820523#comment-13820523
 ] 

Ryan Ernst commented on SOLR-5399:
--

This looks very useful for debugging distributed requests!

A couple minor thoughts on the patch:
* It looks like there is a typo tack vs track, in DebugComponentTest.
* In testModifyRequestTrack() and testPrepare(), it would be nice to add a loop 
so a couple variations can be tested in a single test run (just less reliance 
on jenkins coming up with seeds that will hit possible bugs).
* The REQUEST_PURPOSE parameter name is in CamelCase, but it seems like the 
other request parameters are lowercase.  Maybe make it match stylistically?

+1 in general though.

 Improve DebugComponent for distributed requests
 ---

 Key: SOLR-5399
 URL: https://issues.apache.org/jira/browse/SOLR-5399
 Project: Solr
  Issue Type: Improvement
Affects Versions: 5.0
Reporter: Tomás Fernández Löbbe
 Attachments: SOLR-5399.patch, SOLR-5399.patch


 I'm working on extending the DebugComponent for adding some useful 
 information to be able to track distributed requests better. I'm adding two 
 different things, first, the request can generate a request ID that will be 
 printed in the logs for the main query and all the different internal 
 requests to the different shards. This should make it easier to find the 
 different parts of a single user request in the logs. It would also add the 
 purpose of each internal request to the logs, like: 
 RequestPurpose=GET_FIELDS,GET_DEBUG or RequestPurpose=GET_TOP_IDS. 
 Also, I'm adding a track section to the debug info where to add information 
 about the different phases of the distributed request (right now, I'm only 
 including QTime, but could eventually include more information) like: 
 {code:xml}
 lst name=debug
 lst name=track
 lst name=EXECUTE_QUERY
 str name=localhost:8985/solrQTime: 10/str
 str name=localhost:8984/solrQTime: 25/str
 /lst
 lst name=GET_FIELDS
 str name=localhost:8985/solrQTime: 1/str
 /lst
 /lst
 /lst
 {code}
 To get this, debugQuery must be set to true, or debug must include 
 debug=track. This information is only added to distributed requests.  I 
 would like to get feedback on this.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


 [ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Bernstein updated SOLR-5408:
-

Attachment: CollapsingQParserPlugin.java

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: CollapsingQParserPlugin.java, 
 CollapsingQParserPlugin.java, SOLR-5027.patch, SOLR-5408.2.patch, 
 SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820569#comment-13820569
 ] 

Joel Bernstein commented on SOLR-5408:
--

Brandon,

I put a file up for you to test. I don't have the same build as you have 
anymore so I won't be able to compile and test. But the changes were very 
small, so I suspect they will work.

Joel

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: CollapsingQParserPlugin.java, 
 CollapsingQParserPlugin.java, SOLR-5027.patch, SOLR-5408.2.patch, 
 SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-5408) Collapsing Query Parser does not respect multiple Sort fields


[ 
https://issues.apache.org/jira/browse/SOLR-5408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820575#comment-13820575
 ] 

ASF subversion and git services commented on SOLR-5408:
---

Commit 1541277 from [~joel.bernstein] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1541277 ]

SOLR-5408 Fixed issue with scorer

 Collapsing Query Parser does not respect multiple Sort fields
 -

 Key: SOLR-5408
 URL: https://issues.apache.org/jira/browse/SOLR-5408
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Brandon Chapman
Assignee: Joel Bernstein
Priority: Critical
 Attachments: CollapsingQParserPlugin.java, 
 CollapsingQParserPlugin.java, SOLR-5027.patch, SOLR-5408.2.patch, 
 SOLR-5408.patch, SOLR-5408.patch


 When using the collapsing query parser, only the last sort field appears to 
 be used.
 http://172.18.0.10:8080/solr/product/select_eng?sort=score%20desc,name_sort_eng%20descqf=name_eng^3+brand^2+categories_term_eng+sku+upc+promoTag+model+related_terms_engpf2=name_eng^2defType=edismaxrows=12pf=name_eng~5^3start=0q=ipadboost=sqrt(popularity)qt=/select_engfq=productType:MERCHANDISEfq=merchant:bestbuycanadafq=(*:*+AND+-all_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(all_all_suppressed_b_ovly:false+AND+-rbc_all_suppressed_b_ovly:[*+TO+*]+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_all_suppressed_b_ovly:false+AND+-rbc_cpx_suppressed_b_ovly:[*+TO+*])+OR+(rbc_cpx_suppressed_b_ovly:false)fq=translations:engfl=psid,name_eng,scoredebug=truedebugQuery=truefq={!collapse+field%3DgroupId+nullPolicy%3Dexpand}
 result name=response numFound=5927 start=0 maxScore=5.6674457
 doc
 str name=psid3002010250210/str
 str name=name_eng
 ZOTAC ZBOX nano XS AD13 Plus All-In-One PC (AMD E2-1800/2GB RAM/64GB SSD)
 /str
 float name=score0.41423172/float
 /doc
 The same query without using the collapsing query parser produces the 
 expected result.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[JENKINS] Lucene-Solr-Tests-4.x-Java7 - Build # 1754 - Failure

2013-11-12 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java7/1754/

All tests passed

Build Log:
[...truncated 32812 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
  [javadoc] Loading source files for package org.apache.lucene...
  [javadoc] Loading source files for package org.apache.lucene.analysis...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.tokenattributes...
  [javadoc] Loading source files for package org.apache.lucene.codecs...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.compressing...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene3x...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene40...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene41...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene42...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene45...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.lucene46...
  [javadoc] Loading source files for package 
org.apache.lucene.codecs.perfield...
  [javadoc] Loading source files for package org.apache.lucene.document...
  [javadoc] Loading source files for package org.apache.lucene.index...
  [javadoc] Loading source files for package org.apache.lucene.search...
  [javadoc] Loading source files for package 
org.apache.lucene.search.payloads...
  [javadoc] Loading source files for package 
org.apache.lucene.search.similarities...
  [javadoc] Loading source files for package org.apache.lucene.search.spans...
  [javadoc] Loading source files for package org.apache.lucene.store...
  [javadoc] Loading source files for package org.apache.lucene.util...
  [javadoc] Loading source files for package org.apache.lucene.util.automaton...
  [javadoc] Loading source files for package org.apache.lucene.util.fst...
  [javadoc] Loading source files for package org.apache.lucene.util.mutable...
  [javadoc] Loading source files for package org.apache.lucene.util.packed...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.7.0_25
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Generating 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/build/docs/core/org/apache/lucene/search/package-summary.html...
  [javadoc] Copying file 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-2.png
 to directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/build/docs/core/org/apache/lucene/search/doc-files...
  [javadoc] Copying file 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/core/src/java/org/apache/lucene/search/doc-files/nrq-formula-1.png
 to directory 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/build/docs/core/org/apache/lucene/search/doc-files...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java7/lucene/build/docs/core/help-doc.html...
  [javadoc] 1 warning

[...truncated 27 lines...]
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
  [javadoc] Loading source files for package org.apache.lucene.analysis.ar...
  [javadoc] Loading source files for package org.apache.lucene.analysis.bg...
  [javadoc] Loading source files for package org.apache.lucene.analysis.br...
  [javadoc] Loading source files for package org.apache.lucene.analysis.ca...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.charfilter...
  [javadoc] Loading source files for package org.apache.lucene.analysis.cjk...
  [javadoc] Loading source files for package org.apache.lucene.analysis.cn...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.commongrams...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.compound...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.compound.hyphenation...
  [javadoc] Loading source files for package org.apache.lucene.analysis.core...
  [javadoc] Loading source files for package org.apache.lucene.analysis.cz...
  [javadoc] Loading source files for package org.apache.lucene.analysis.da...
  [javadoc] Loading source files for package org.apache.lucene.analysis.de...
  [javadoc] Loading source files for package org.apache.lucene.analysis.el...
  [javadoc] Loading source files for package org.apache.lucene.analysis.en...
  [javadoc] Loading source files for package org.apache.lucene.analysis.es...
  [javadoc] Loading source files for package

[jira] [Created] (LUCENE-5339) Simplify the facet module APIs

2013-11-12 Thread Michael McCandless (JIRA)

Michael McCandless created LUCENE-5339:
--

 Summary: Simplify the facet module APIs
 Key: LUCENE-5339
 URL: https://issues.apache.org/jira/browse/LUCENE-5339
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Michael McCandless
Assignee: Michael McCandless


I'd like to explore simplifications to the facet module's APIs: I
think the current APIs are complex, and the addition of a new feature
(sparse faceting, LUCENE-5333) threatens to add even more classes
(e.g., FacetRequestBuilder).  I think we can do better.

So, I've been prototyping some drastic changes; this is very
early/exploratory and I'm not sure where it'll wind up but I think the
new approach shows promise.

The big changes are:

  * Instead of *FacetRequest/Params/Result, you directly instantiate
the classes that do facet counting (currently TaxonomyFacetCounts,
RangeFacetCounts or SortedSetDVFacetCounts), passing in the
SimpleFacetsCollector, and then you interact with those classes to
pull labels + values (topN under a path, sparse, specific labels).

  * At index time, no more FacetIndexingParams/CategoryListParams;
instead, you make a new SimpleFacetFields and pass it the field it
should store facets + drill downs under.  If you want more than
one CLI you create more than one instance of SimpleFacetFields.

  * I added a simple schema, where you state which dimensions are
hierarchical or multi-valued.  From this we decide how to index
the ordinals (no more OrdinalPolicy).

Sparse faceting is just another method (getAllDims), on both taxonomy
 ssdv facet classes.

I haven't created a common base class / interface for all of the
search-time facet classes, but I think this may be possible/clean, and
perhaps useful for drill sideways.

All the new classes are under oal.facet.simple.*.

Lots of things that don't work yet: drill sideways, complements,
associations, sampling, partitions, etc.  This is just a start ...




--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (LUCENE-5339) Simplify the facet module APIs

2013-11-12 Thread Michael McCandless (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-5339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael McCandless updated LUCENE-5339:
---

Attachment: LUCENE-5339.patch

Starting patch.

Simplify the facet module APIs
--

Key: LUCENE-5339
URL: https://issues.apache.org/jira/browse/LUCENE-5339
Project: Lucene - Core
Issue Type: Improvement
Components: modules/facet
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-5339.patch

I'd like to explore simplifications to the facet module's APIs: I
think the current APIs are complex, and the addition of a new feature
(sparse faceting, LUCENE-5333) threatens to add even more classes
(e.g., FacetRequestBuilder). I think we can do better.
So, I've been prototyping some drastic changes; this is very
early/exploratory and I'm not sure where it'll wind up but I think the
new approach shows promise.
The big changes are:
* Instead of *FacetRequest/Params/Result, you directly instantiate
the classes that do facet counting (currently TaxonomyFacetCounts,
RangeFacetCounts or SortedSetDVFacetCounts), passing in the
SimpleFacetsCollector, and then you interact with those classes to
pull labels + values (topN under a path, sparse, specific labels).
* At index time, no more FacetIndexingParams/CategoryListParams;
instead, you make a new SimpleFacetFields and pass it the field it
should store facets + drill downs under. If you want more than
one CLI you create more than one instance of SimpleFacetFields.
* I added a simple schema, where you state which dimensions are
hierarchical or multi-valued. From this we decide how to index
the ordinals (no more OrdinalPolicy).
Sparse faceting is just another method (getAllDims), on both taxonomy
ssdv facet classes.
I haven't created a common base class / interface for all of the
search-time facet classes, but I think this may be possible/clean, and
perhaps useful for drill sideways.
All the new classes are under oal.facet.simple.*.
Lots of things that don't work yet: drill sideways, complements,
associations, sampling, partitions, etc. This is just a start ...

--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Created] (SOLR-5438) DebugComponent throws NPE when used with grouping

2013-11-12 Thread JIRA

Tomás Fernández Löbbe created SOLR-5438:
---

 Summary: DebugComponent throws NPE when used with grouping
 Key: SOLR-5438
 URL: https://issues.apache.org/jira/browse/SOLR-5438
 Project: Solr
  Issue Type: Bug
Reporter: Tomás Fernández Löbbe


To Reproduce: 
start trunk example
Run query:  
http://localhost:8983/solr/select?q=testdebug=truegroup=truegroup.field=inStockdistrib=trueshards=localhost:8983/solr,localhost:8983/solr

DebugComponent throws a NPE like: 
{noformat}
83841 [qtp1070887245-16] ERROR org.apache.solr.servlet.SolrDispatchFilter  – 
null:java.lang.NullPointerException
at 
org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:66)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:216)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at 
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at 
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)
at 
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at 
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at 
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:722)
{noformat}
Seems like some internal requests when using grouping don't populate 
ResponseBuilder.results. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-5438) DebugComponent throws NPE when used with grouping

2013-11-12 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/SOLR-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomás Fernández Löbbe updated SOLR-5438:


Attachment: SOLR-5438.patch

The problem seems to be when getting the doc explain. This can be done in the 
last grouping phase. 

 DebugComponent throws NPE when used with grouping
 -

 Key: SOLR-5438
 URL: https://issues.apache.org/jira/browse/SOLR-5438
 Project: Solr
  Issue Type: Bug
Reporter: Tomás Fernández Löbbe
 Attachments: SOLR-5438.patch


 To Reproduce: 
 start trunk example
 Run query:  
 http://localhost:8983/solr/select?q=testdebug=truegroup=truegroup.field=inStockdistrib=trueshards=localhost:8983/solr,localhost:8983/solr
 DebugComponent throws a NPE like: 
 {noformat}
 83841 [qtp1070887245-16] ERROR org.apache.solr.servlet.SolrDispatchFilter  – 
 null:java.lang.NullPointerException
 at 
 org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:66)
 at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:216)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
 at 
 org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
 at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
 at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
 at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
 at 
 org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
 at 
 org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
 at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
 at 
 org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
 at 
 org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
 at 
 org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
 at 
 org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
 at 
 org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
 at 
 org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
 at org.eclipse.jetty.server.Server.handle(Server.java:368)
 at 
 org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
 at 
 org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
 at 
 org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)
 at 
 org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)
 at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)
 at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
 at 
 org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
 at 
 org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
 at 
 org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
 at 
 org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
 at java.lang.Thread.run(Thread.java:722)
 {noformat}
 Seems like some internal requests when using grouping don't populate 
 ResponseBuilder.results. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Resolved] (SOLR-5247) Support for custom per core properties missing with new-style solr.xml

2013-11-12 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson resolved SOLR-5247.
--

   Resolution: Fixed
Fix Version/s: 4.5
   5.0

[~n0v1] I just tried this and it seems to work fine for core creation on 4.5 
and 4x. I know there has been quite a bit of work in this area _right_ after 
the 4.4 Solr was cut so I'm going to say it's fixed.

If anyone finds out differently, we can re-open this JIRA or open a new one.

 Support for custom per core properties missing with new-style solr.xml
 --

 Key: SOLR-5247
 URL: https://issues.apache.org/jira/browse/SOLR-5247
 Project: Solr
  Issue Type: Bug
  Components: multicore
Affects Versions: 4.4
Reporter: Chris F
Assignee: Erick Erickson
Priority: Trivial
  Labels: 4.4, core.properties, discovery, new-style, property, 
 solr.xml
 Fix For: 5.0, 4.5


 This part has been solved. See comments
 When using old-style solr.xml I can define custom properties per core like so:
 {code:xml}
 cores adminPath=/admin/cores defaultCoreName=core1
   core name=core1 instanceDir=core1 config=solrconfig.xml 
 schema=schema.xml
 property name=foo value=bar /
   /core
 /cores
 {code}
 I can then use the property foo in schema.xml or solrconfig.xml like this:
 {code:xml}
 str name=foo${foo}/str
 {code}
 After switching to the new-style solr.xml with separate core.properties files 
 per core this does not work anymore.
 I guess the corresponding core.properties file should look like this:
 {code}
 config=solrconfig.xml
 name=core1
 schema=schema.xml
 foo=bar
 {code}
 (I also tried property.foo=bar)
 With that, I get the following error when reloading the core:
 {code}
 org.apache.solr.common.SolrException:org.apache.solr.common.SolrException: No 
 system property or default value specified for foo value:${foo}
 {code}
 I can successfully reload the core if I use $\{foo:undefined\} but the value 
 of foo will always be undefined then.
 When trying to create a new core with an url like this:
 {code}
 http://localhost:8080/solr/admin/cores?action=CREATEname=core2instanceDir=core2config=solrconfig.xmlschema=schema.xmlproperty.foo=barpersist=true
 {code}
 the property foo will not appear in core.properties. However, I can use it 
 in schema.xml. But only until restarting the servlet container. After that, 
 the property is lost.
 Possibly related to 
 [SOLR-5208|https://issues.apache.org/jira/browse/SOLR-5208]?



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 1013 - Failure!

2013-11-12 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/1013/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 10035 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20131113_000940_422.syserr
   [junit4]  JVM J0: stderr (verbatim) 
   [junit4] java(287,0x130443000) malloc: *** error for object 
0x2130431e90: pointer being freed was not allocated
   [junit4] *** set a breakpoint in malloc_error_break to debug
   [junit4]  JVM J0: EOF 

[...truncated 1 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/java 
-XX:-UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/heapdumps 
-Dtests.prefix=tests -Dtests.seed=58426B9B97062A82 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 
-Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/temp
 
-Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/tests.policy
 -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Dtests.disableHdfs=true -Dfile.encoding=ISO-8859-1 
-classpath

[jira] [Commented] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable


[ 
https://issues.apache.org/jira/browse/LUCENE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820757#comment-13820757
 ] 

ASF subversion and git services commented on LUCENE-5337:
-

Commit 1541341 from [~erickoerickson] in branch 'dev/trunk'
[ https://svn.apache.org/r1541341 ]

LUCENE-5337 Add Payload support to FileDictionary (Suggest) and make it more 
configurable

 Add Payload support to FileDictionary (Suggest) and make it more configurable
 -

 Key: LUCENE-5337
 URL: https://issues.apache.org/jira/browse/LUCENE-5337
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Areek Zillur
 Attachments: LUCENE-5337.patch, LUCENE-5337.patch, LUCENE-5337.patch


 It would be nice to add payload support to FileDictionary, so user can pass 
 in associated payload with suggestion entries. 
 Currently the FileDictionary has a hard-coded field-delimiter (TAB), it would 
 be nice to let the users configure the field delimiter as well.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820796#comment-13820796
 ] 

Robert Muir commented on LUCENE-5337:
-

Does this one really go in 4.6.0? Seems like this was just a mistake and it 
should be 4.7.0?

Note: I created 4.7.0 section of CHANGES already and branch_4x is set for 
4.7.0. So i think the CHANGES entry just needs to be moved.

 Add Payload support to FileDictionary (Suggest) and make it more configurable
 -

 Key: LUCENE-5337
 URL: https://issues.apache.org/jira/browse/LUCENE-5337
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Areek Zillur
 Attachments: LUCENE-5337.patch, LUCENE-5337.patch, LUCENE-5337.patch


 It would be nice to add payload support to FileDictionary, so user can pass 
 in associated payload with suggestion entries. 
 Currently the FileDictionary has a hard-coded field-delimiter (TAB), it would 
 be nice to let the users configure the field delimiter as well.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5322) Clean up / simplify Maven-related Ant targets


[ 
https://issues.apache.org/jira/browse/LUCENE-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820833#comment-13820833
 ] 

ASF subversion and git services commented on LUCENE-5322:
-

Commit 1541355 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1541355 ]

Move LUCENE-5217 and LUCENE-5322 entries to the 4.7 section

 Clean up / simplify Maven-related Ant targets
 -

 Key: LUCENE-5322
 URL: https://issues.apache.org/jira/browse/LUCENE-5322
 Project: Lucene - Core
  Issue Type: Task
  Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
Priority: Minor
 Fix For: 4.6, 5.0

 Attachments: LUCENE-5322.patch, 
 LUCENE-5322.validate-maven-artifacts.patch


 Many Maven-related Ant targets are public when they don't need to be, e.g. 
 dist-maven and filter-pom-templates, m2-deploy-lucene-parent-pom, etc.
 The arrangement of these targets could be simplified if the directories that 
 have public entry points were minimized.
 generate-maven-artifacts should be runnable from the top level and from 
 lucene/ and solr/. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5217) disable transitive dependencies in maven config

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820832#comment-13820832
 ] 

ASF subversion and git services commented on LUCENE-5217:
-

Commit 1541355 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1541355 ]

Move LUCENE-5217 and LUCENE-5322 entries to the 4.7 section

 disable transitive dependencies in maven config
 ---

 Key: LUCENE-5217
 URL: https://issues.apache.org/jira/browse/LUCENE-5217
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Steve Rowe
 Fix For: 4.6, 5.0

 Attachments: LUCENE-5217.patch, LUCENE-5217.patch, LUCENE-5217.patch, 
 LUCENE-5217.patch


 Our ivy configuration does this: each dependency is specified and so we know 
 what will happen. Unfortunately the maven setup is not configured the same 
 way.
 Instead the maven setup is configured to download the internet: and it 
 excludes certain things specifically.
 This is really hard to configure and maintain: we added a 
 'validate-maven-dependencies' that tries to fail on any extra jars, but all 
 it really does is run a license check after maven runs. It wouldnt find 
 unnecessary dependencies being dragged in if something else in lucene was 
 using them and thus they had a license file.
 Since maven supports wildcard exclusions: MNG-3832, we can disable this 
 transitive shit completely.
 We should do this, so its configuration is the exact parallel of ivy.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5217) disable transitive dependencies in maven config

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820840#comment-13820840
 ] 

ASF subversion and git services commented on LUCENE-5217:
-

Commit 1541357 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1541357 ]

Backport LUCENE-5217 and LUCENE-5322 to branch_4x

 disable transitive dependencies in maven config
 ---

 Key: LUCENE-5217
 URL: https://issues.apache.org/jira/browse/LUCENE-5217
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
Assignee: Steve Rowe
 Fix For: 4.6, 5.0

 Attachments: LUCENE-5217.patch, LUCENE-5217.patch, LUCENE-5217.patch, 
 LUCENE-5217.patch


 Our ivy configuration does this: each dependency is specified and so we know 
 what will happen. Unfortunately the maven setup is not configured the same 
 way.
 Instead the maven setup is configured to download the internet: and it 
 excludes certain things specifically.
 This is really hard to configure and maintain: we added a 
 'validate-maven-dependencies' that tries to fail on any extra jars, but all 
 it really does is run a license check after maven runs. It wouldnt find 
 unnecessary dependencies being dragged in if something else in lucene was 
 using them and thus they had a license file.
 Since maven supports wildcard exclusions: MNG-3832, we can disable this 
 transitive shit completely.
 We should do this, so its configuration is the exact parallel of ivy.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5322) Clean up / simplify Maven-related Ant targets

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820841#comment-13820841
 ] 

ASF subversion and git services commented on LUCENE-5322:
-

Commit 1541357 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1541357 ]

Backport LUCENE-5217 and LUCENE-5322 to branch_4x

 Clean up / simplify Maven-related Ant targets
 -

 Key: LUCENE-5322
 URL: https://issues.apache.org/jira/browse/LUCENE-5322
 Project: Lucene - Core
  Issue Type: Task
  Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
Priority: Minor
 Fix For: 4.6, 5.0

 Attachments: LUCENE-5322.patch, 
 LUCENE-5322.validate-maven-artifacts.patch


 Many Maven-related Ant targets are public when they don't need to be, e.g. 
 dist-maven and filter-pom-templates, m2-deploy-lucene-parent-pom, etc.
 The arrangement of these targets could be simplified if the directories that 
 have public entry points were minimized.
 generate-maven-artifacts should be runnable from the top level and from 
 lucene/ and solr/. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable

2013-11-12 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820846#comment-13820846
 ] 

ASF subversion and git services commented on LUCENE-5337:
-

Commit 1541360 from [~erickoerickson] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1541360 ]

LUCENE-5337 Add Payload support to FileDictionary (Suggest) and make it more 
configurable

 Add Payload support to FileDictionary (Suggest) and make it more configurable
 -

 Key: LUCENE-5337
 URL: https://issues.apache.org/jira/browse/LUCENE-5337
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Areek Zillur
 Attachments: LUCENE-5337.patch, LUCENE-5337.patch, LUCENE-5337.patch


 It would be nice to add payload support to FileDictionary, so user can pass 
 in associated payload with suggestion entries. 
 Currently the FileDictionary has a hard-coded field-delimiter (TAB), it would 
 be nice to let the users configure the field delimiter as well.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-5287) Allow at least solrconfig.xml and schema.xml to be edited via the admin screen

[
https://issues.apache.org/jira/browse/SOLR-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Erick Erickson updated SOLR-5287:
-

Attachment: SOLR-5287.patch

Well, this is scary. I hacked together a butchery of ShowFileRequestHandler (so
far only local no ZK support).

The most work was refactoring this a bit so I could re-use some of the work
already there.

But it...works. Even updating files in subdirectories of conf, e.g. velocity.

It turns out that ShowFileRequestHandler _already_ lists the contents of a
directory if it is a directory. So something like:

http://localhost:8983/solr/collection1/admin/file?file=velocity

will list the contents of the conf/velocity, and

http://localhost:8983/solr/collection1/admin/file

will list the contents of the conf directory itself.

So, adding a param op=write and file=whatever and posting a stream to Solr
just works. These two curl commands did the trick, giving me a stream to work
with:

curl -X POST --form fileupload=@schema.eoe
'http://localhost:8983/solr/collection1/admin/file?op=writefile=schema.xml'

curl -X POST --form fileupload=@eoe.vm
'http://localhost:8983/solr/collection1/admin/file?op=writefile=velocity/error.vm'

[~steffkes] Is this enough to see if this could work from the admin UI?

Everyone: Mostly I'm putting this up to see what people think. [~sarowe] and I
chatted this evening, there are still some questions about how this and managed
schemas should interact when both are active at once.

You can also hide files if you so choose, the code already does that. If the UI
gives you a set of files to choose from you just wouldn't see one to try to
change although you could still cURL stuff if you wanted, but this is the admin
UI after all.

If you opened a binary file, I assume you'd see garbage and wouldn't want to
proceed anyway, but that's a bit of a hole.

We should post a warning indicating that the changes won't take effect until
after a core reload. I'm reluctant to actually reload automatically on the
theory that one might want to make a series of related changes and apply them
all at once. Perhaps [~steffkes] (or someone) could put a button on whatever
page we come up with rather than making the user go to the cores page after
editing?

What would be _really cool_ is if there were an easy way to tell if at least
the xml was well-formed before saving, but that's a bell and whistle.

One thing that we may get for free is editing these even if the core fails to
load. But I have to check that out when the admin UI is operational.

And I still have to check whether lazily-loaded cores work, but this is enough
for tonight.

And, as usual at this point, I haven't checked things over very carefully, run
precommit or test yet. Mostly I'm wondering what people think of the approach.

Let me know...

Allow at least solrconfig.xml and schema.xml to be edited via the admin screen
--

Key: SOLR-5287
URL: https://issues.apache.org/jira/browse/SOLR-5287
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis, web gui
Affects Versions: 4.5, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Attachments: SOLR-5287.patch

A user asking a question on the Solr list got me to thinking about editing
the main config files from the Solr admin screen. I chatted briefly with
[~steffkes] about the mechanics of this on the browser side, he doesn't see a
problem on that end. His comment is there's no end point that'll write the
file back.
Am I missing something here or is this actually not a hard problem? I see a
couple of issues off the bat, neither of which seem troublesome.
1 file permissions. I'd imagine lots of installations will get file
permission exceptions if Solr tries to write the file out. Well, do a
chmod/chown.
2 screwing up the system maliciously or not. I don't think this is an issue,
this would be part of the admin handler after all.
Does anyone have objections to the idea? And how does this fit into the work
that [~sar...@syr.edu] has been doing?
I can imagine this extending to SolrCloud with a push this to ZK option or
something like that, perhaps not in V1 unless it's easy.
Of course any pointers gratefully received. Especially ones that start with
Don't waste your effort, it'll never work (or be accepted)...
Because what scares me is this seems like such an easy thing to do that would
be a significant ease-of-use improvement, so there _has_ to be something I'm
missing.
So if we go forward with this we'll make this the umbrella JIRA, the two
immediate sub-JIRAs that spring to mind will be the UI work and the endpoints
for the UI work to use.
I think there are only two end-points here
1 list all the files in the

[jira] [Commented] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable


[ 
https://issues.apache.org/jira/browse/LUCENE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13820866#comment-13820866
 ] 

Erick Erickson commented on LUCENE-5337:


Robert: 

You're right, of course. Thanks!

I'll fix momentarily.

 Add Payload support to FileDictionary (Suggest) and make it more configurable
 -

 Key: LUCENE-5337
 URL: https://issues.apache.org/jira/browse/LUCENE-5337
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Areek Zillur
 Attachments: LUCENE-5337.patch, LUCENE-5337.patch, LUCENE-5337.patch


 It would be nice to add payload support to FileDictionary, so user can pass 
 in associated payload with suggestion entries. 
 Currently the FileDictionary has a hard-coded field-delimiter (TAB), it would 
 be nice to let the users configure the field delimiter as well.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Resolved] (LUCENE-5337) Add Payload support to FileDictionary (Suggest) and make it more configurable