date:20130404


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

Adrien Grand updated LUCENE-4874:
-

Summary: Don't override non abstract methods in FilterAtomicReader and 
related classes  (was: Remove FilterTerms.intersect)

 Don't override non abstract methods in FilterAtomicReader and related classes
 -

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


 Terms.intersect is an optional method. The fact that it is overridden in 
 FilterTerms forces any non-trivial class that extends FilterTerms to override 
 intersect in order this method to have a correct behavior. If FilterTerms did 
 not override this method and used the default impl, we would not have this 
 problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4666) JSON Formating


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

nihed mbarek commented on SOLR-4666:


[~hossman] for me the problem is not limited to the field score but many with 
different standard type (string, int, float, ...) 
I'm trying to reproduce the problem with a new schema for a sample set of data. 

Sorry, I can't communicate my actual schema/result for confidentiality issues 

 JSON Formating
 --

 Key: SOLR-4666
 URL: https://issues.apache.org/jira/browse/SOLR-4666
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Linux server with Tomcat as application server 
Reporter: nihed mbarek

 Dear, 
 We discover that some fields (not multivalued) was formated as multivalued 
 for JSON output when on our schema we add : 
 bq.   ??dynamicField name=* type=ignored multiValued=true /??
 in other terms, an internal field like score will be displayed as : 
 bq. ??score:[2.9204934],??
 and not :
 bq. ??score:4.5376997,??
 there is no problem with xml output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4381) Query-time multi-word synonym expansion

2013-04-04 Thread Okke Klein (JIRA)

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

Okke Klein commented on SOLR-4381:
--

The terms that are being expanded by the solr.SynonymFilterFactory are also
being stemmed. This is unwanted if you want to expand MIA to missing in
action and not miss in action. See [Github
issue|https://github.com/healthonnet/hon-lucene-synonyms/issues/14] for details.

Query-time multi-word synonym expansion
---

Key: SOLR-4381
URL: https://issues.apache.org/jira/browse/SOLR-4381
Project: Solr
Issue Type: Improvement
Components: query parsers
Reporter: Nolan Lawson
Priority: Minor
Labels: multi-word, queryparser, synonyms
Fix For: 4.3

Attachments: SOLR-4381-2.patch, SOLR-4381.patch

This is an issue that seems to come up perennially.
The [Solr
docs|http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory]
caution that index-time synonym expansion should be preferred to query-time
synonym expansion, due to the way multi-word synonyms are treated and how IDF
values can be boosted artificially. But query-time expansion should have huge
benefits, given that changes to the synonyms don't require re-indexing, the
index size stays the same, and the IDF values for the documents don't get
permanently altered.
The proposed solution is to move the synonym expansion logic from the
analysis chain (either query- or index-type) and into a new QueryParser. See
the attached patch for an implementation.
The core Lucene functionality is untouched. Instead, the EDismaxQParser is
extended, and synonym expansion is done on-the-fly. Queries are parsed into
a lattice (i.e. all possible synonym combinations), while individual
components of the query are still handled by the EDismaxQParser itself.
It's not an ideal solution by any stretch. But it's nice and self-contained,
so it invites experimentation and improvement. And I think it fits in well
with the merry band of misfit query parsers, like {{func}} and {{frange}}.
More details about this solution can be found in [this blog
post|http://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/] and
[the Github page for the
code|https://github.com/healthonnet/hon-lucene-synonyms].
At the risk of tooting my own horn, I also think this patch sufficiently
fixes SOLR-3390 (highlighting problems with multi-word synonyms) and
LUCENE-4499 (better support for multi-word synonyms).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4858) Early termination with SortingMergePolicy


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

Shai Erera updated LUCENE-4858:
---

Attachment: LUCENE-4858.patch

Patch adds Sorter.getID() and the collector to check whether the given Sorter 
matches the one that's recorded in the segment. I added a test to 
TestEarlyTermination which fails if the added check to sorted() is removed.

 Early termination with SortingMergePolicy
 -

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

 Attachments: LUCENE-4858.patch, LUCENE-4858.patch, LUCENE-4858.patch


 Spin-off of LUCENE-4752, see 
 https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13606565page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13606565
  and 
 https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13607282page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13607282
 When an index is sorted per-segment, queries that sort according to the index 
 sort order could be early terminated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4666) JSON Formating


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

nihed mbarek commented on SOLR-4666:


[~hossman] I just reproduce the problem with the default collection1 example.
to do that I used the default schema with 
dynamicField name=* type=ignored multiValued=true /

my new discover is that the problem concern the alias : 

for example 
for fl = score, idProd:id
I will have : 
 {
score:[1.0],
idProd:[GB18030TEST]},
  {
score:[1.0],
idProd:[SP2514N]},
  {
score:[1.0],
idProd:[6H500F0]},

 JSON Formating
 --

 Key: SOLR-4666
 URL: https://issues.apache.org/jira/browse/SOLR-4666
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Linux server with Tomcat as application server 
Reporter: nihed mbarek

 Dear, 
 We discover that some fields (not multivalued) was formated as multivalued 
 for JSON output when on our schema we add : 
 bq.   ??dynamicField name=* type=ignored multiValued=true /??
 in other terms, an internal field like score will be displayed as : 
 bq. ??score:[2.9204934],??
 and not :
 bq. ??score:4.5376997,??
 there is no problem with xml output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4666) JSON Formating


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

nihed mbarek updated SOLR-4666:
---

Attachment: schema.xml

 JSON Formating
 --

 Key: SOLR-4666
 URL: https://issues.apache.org/jira/browse/SOLR-4666
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Linux server with Tomcat as application server 
Reporter: nihed mbarek
 Attachments: schema.xml


 Dear, 
 We discover that some fields (not multivalued) was formated as multivalued 
 for JSON output when on our schema we add : 
 bq.   ??dynamicField name=* type=ignored multiValued=true /??
 in other terms, an internal field like score will be displayed as : 
 bq. ??score:[2.9204934],??
 and not :
 bq. ??score:4.5376997,??
 there is no problem with xml output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (SOLR-4666) JSON Formating


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

nihed mbarek edited comment on SOLR-4666 at 4/4/13 9:23 AM:


[~hossman] I just reproduce the problem with the default collection1 example.
to do that I used the default schema with 
dynamicField name=* type=ignored multiValued=true /

schema link : 
https://issues.apache.org/jira/secure/attachment/12576952/schema.xml

my new discover is that the problem concern the alias : 

for example 
for fl = score, idProd:id
I will have : 
 {
score:[1.0],
idProd:[GB18030TEST]},
  {
score:[1.0],
idProd:[SP2514N]},
  {
score:[1.0],
idProd:[6H500F0]},

  was (Author: nihed):
[~hossman] I just reproduce the problem with the default collection1 
example.
to do that I used the default schema with 
dynamicField name=* type=ignored multiValued=true /

my new discover is that the problem concern the alias : 

for example 
for fl = score, idProd:id
I will have : 
 {
score:[1.0],
idProd:[GB18030TEST]},
  {
score:[1.0],
idProd:[SP2514N]},
  {
score:[1.0],
idProd:[6H500F0]},
  
 JSON Formating
 --

 Key: SOLR-4666
 URL: https://issues.apache.org/jira/browse/SOLR-4666
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Linux server with Tomcat as application server 
Reporter: nihed mbarek
 Attachments: schema.xml


 Dear, 
 We discover that some fields (not multivalued) was formated as multivalued 
 for JSON output when on our schema we add : 
 bq.   ??dynamicField name=* type=ignored multiValued=true /??
 in other terms, an internal field like score will be displayed as : 
 bq. ??score:[2.9204934],??
 and not :
 bq. ??score:4.5376997,??
 there is no problem with xml output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-3076) Solr should support block joins

2013-04-04 Thread Vadim Kirilchuk (JIRA)


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

Vadim Kirilchuk updated SOLR-3076:
--

Attachment: dih-3076.patch
dih-config.xml

Hi everyone!

I am attaching draft dih patch (and sample dih-config) which adds support of 
hierarchical docs to dih.

It is far from being complete but works for me and can be useful for others.

Any Feedback Is Appreciated. Thanks.


 



 Solr should support block joins
 ---

 Key: SOLR-3076
 URL: https://issues.apache.org/jira/browse/SOLR-3076
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
 Fix For: 5.0

 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, 
 bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, 
 child-bjqparser.patch, dih-3076.patch, dih-config.xml, 
 parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 
 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, 
 SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, 
 solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, 
 tochild-bjq-filtered-search-fix.patch


 Lucene has the ability to do block joins, we should add it to Solr.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4670) Core mismatch in concurrent documents creation

2013-04-04 Thread Alberto Ferrini (JIRA)

Alberto Ferrini created SOLR-4670:
-

 Summary: Core mismatch in concurrent documents creation
 Key: SOLR-4670
 URL: https://issues.apache.org/jira/browse/SOLR-4670
 Project: Solr
  Issue Type: Bug
  Components: multicore, SolrCloud
Affects Versions: 4.2, 4.1, 4.0
 Environment: CPU: 32x AMD Opteron(TM) Processor 6276
RAM: 132073620 kB
OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga)

JDK 1.6.0_21
JBoss [EAP] 4.3.0.GA_CP09
Apache Solr 4.x
Apache ZooKeeper 3.4.5

Reporter: Alberto Ferrini


The issue can be reproduced in this way:
- Install SolrCloud with at least 2 nodes
- Install ZooKeeper with at least 2 nodes
- Create 30 cores
- After each core creation, create 20 random generated documents in a random 
existent core with 2 concurrent threads on all solr nodes (for example, 
document 1 in core 3 on node 1, document 2 in core 5 on node 1, document 3 in 
core 3 on node 2, etc...).
- After all cores creation, query each core for all documents and compare 
insert data with query result
Some documents result in different core than they are created.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4897) Add a sugar API for traversing categories.


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

Shai Erera updated LUCENE-4897:
---

Attachment: LUCENE-4897.patch

Added TaxoReader.getChildren(int ordinal) and corresponding test. I also 
migrated PrintTaxonomyStats to use getChildren, which removed all mentions of 
ParallelTaxonomyArrays from it.

 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial
  Labels: newdev
 Attachments: LUCENE-4897.patch


 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4670) Core mismatch in concurrent documents creation

2013-04-04 Thread Alberto Ferrini (JIRA)


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

Alberto Ferrini updated SOLR-4670:
--

Description: 
The issue can be reproduced in this way:
- Install SolrCloud with at least 2 nodes
- Install ZooKeeper with at least 2 nodes
- Create 30 cores
- After each core creation, create 20 random generated documents in a random 
existent core with 2 concurrent threads on all solr nodes (for example, 
document 1 in core 3 on node 1, document 2 in core 5 on node 1, document 3 in 
core 3 on node 2, etc...).
- After all cores creation, query each core for all documents and compare 
insert data with query result

Some documents result in different core than they are created.


  was:
The issue can be reproduced in this way:
- Install SolrCloud with at least 2 nodes
- Install ZooKeeper with at least 2 nodes
- Create 30 cores
- After each core creation, create 20 random generated documents in a random 
existent core with 2 concurrent threads on all solr nodes (for example, 
document 1 in core 3 on node 1, document 2 in core 5 on node 1, document 3 in 
core 3 on node 2, etc...).
- After all cores creation, query each core for all documents and compare 
insert data with query result
Some documents result in different core than they are created.



 Core mismatch in concurrent documents creation
 --

 Key: SOLR-4670
 URL: https://issues.apache.org/jira/browse/SOLR-4670
 Project: Solr
  Issue Type: Bug
  Components: multicore, SolrCloud
Affects Versions: 4.0, 4.1, 4.2
 Environment: CPU: 32x AMD Opteron(TM) Processor 6276
 RAM: 132073620 kB
 OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga)
 JDK 1.6.0_21
 JBoss [EAP] 4.3.0.GA_CP09
 Apache Solr 4.x
 Apache ZooKeeper 3.4.5
Reporter: Alberto Ferrini
  Labels: concurrency, multicore, solrcloud, zookeeper

 The issue can be reproduced in this way:
 - Install SolrCloud with at least 2 nodes
 - Install ZooKeeper with at least 2 nodes
 - Create 30 cores
 - After each core creation, create 20 random generated documents in a random 
 existent core with 2 concurrent threads on all solr nodes (for example, 
 document 1 in core 3 on node 1, document 2 in core 5 on node 1, document 3 in 
 core 3 on node 2, etc...).
 - After all cores creation, query each core for all documents and compare 
 insert data with query result
 Some documents result in different core than they are created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4897) Add a sugar API for traversing categories.


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

Michael McCandless commented on LUCENE-4897:


Shouldn't next() throw NoSuchElementException if child is already 
INVALID_ORDINAL?  It shouldn't ever return INVALID_ORDINAL, right?  Ie, caller 
screwed up and called next w/o calling hasNext first.

 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial
  Labels: newdev
 Attachments: LUCENE-4897.patch


 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4897) Add a sugar API for traversing categories.


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

Michael McCandless commented on LUCENE-4897:


Or we could return a not-Java-iterator, that just has int next() that returns 
INVALID_ORDINAL when it's done...

 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial
  Labels: newdev
 Attachments: LUCENE-4897.patch


 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4897) Add a sugar API for traversing categories.


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

Michael McCandless commented on LUCENE-4897:


Woops, our comments crossed...

bq. I wished that we had a simple IntIterator interface with only next() for 
this case...

+1, I think that's best.


 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial
  Labels: newdev
 Attachments: LUCENE-4897.patch


 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-4898) Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT


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

Michael McCandless resolved LUCENE-4898.


   Resolution: Fixed
Fix Version/s: 4.3
   5.0

 Allow DirectoryReader.openIfChanged to an IndexCommit when reader is NRT
 

 Key: LUCENE-4898
 URL: https://issues.apache.org/jira/browse/LUCENE-4898
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4898.patch


 This throws an IllegalArRgumentException today, but it's easy to fix
 with a small change to DirectoryReader.  This is useful to do, if you
 have an NRT reader and want to open a reader against a previous commit
 point while sharing the SegmentReaders they have in common.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4897) Add a sugar API for traversing categories.


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

Shai Erera commented on LUCENE-4897:


I wanted to avoid introducing another class (facet collections already use this 
primitive IntIterator), but maybe a ChildrenIterator with next() is simplest. 
I'll look into it.

 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial
  Labels: newdev
 Attachments: LUCENE-4897.patch


 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4897) Add a sugar API for traversing categories.


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

Shai Erera updated LUCENE-4897:
---

Attachment: LUCENE-4897.patch

Patch with ChildrenIterator

 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial
  Labels: newdev
 Attachments: LUCENE-4897.patch, LUCENE-4897.patch


 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4666) JSON Formating


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

Yonik Seeley commented on SOLR-4666:


I can't seem to produce this on trunk with normal or distributed search.


 JSON Formating
 --

 Key: SOLR-4666
 URL: https://issues.apache.org/jira/browse/SOLR-4666
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Linux server with Tomcat as application server 
Reporter: nihed mbarek
 Attachments: schema.xml


 Dear, 
 We discover that some fields (not multivalued) was formated as multivalued 
 for JSON output when on our schema we add : 
 bq.   ??dynamicField name=* type=ignored multiValued=true /??
 in other terms, an internal field like score will be displayed as : 
 bq. ??score:[2.9204934],??
 and not :
 bq. ??score:4.5376997,??
 there is no problem with xml output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4648) Create a PreAnalyzedUpdateProcessor

2013-04-04 Thread Andrzej Bialecki (JIRA)

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

Andrzej Bialecki commented on SOLR-4648:
-

Thanks again for a thorough review. New patch is attached.

bq. in Solr, it's bad form to call Class.forName() ..

Fixed.

bq. minor: you're using 4-spaces indent instead of 2 in the main value loop in
your URP

Fixed (it was actually a left-over from removing an outer-level loop, all other
indents are 2 spaces).

bq. in those log.debug() calls, it's creating the string to potentially not
even log it

Fixed.

bq. Looking at what FieldType.createField() is doing, I propose you do the
same in this URP ...

Funny thing, I had this in one version of the patch, and then decided to reuse
SF.createField(..) to avoid code duplication. The problem is that
SchemaField.isTokenized() has package-level visibility so it's not visible in
the UP's package. I fixed this by providing a utility method in
PreAnalyzedField to create a FieldType. Also, I moved there the chunk of logic
for setting / resetting the Field content and type flags based on SchemaField.
Overall, it simplifies the UP.

bq. The resulting Field instance can be shared from one document to the next
I believe, and so you can cache this in the URP and reset its value
tokenStream.

Hmm, this doesn't seem feasible at all. First, this cache would have to be
thread safe, and prevent reuse of Field instances until the document is
actually processed by IndexWriter - I don't think there's a mechanism to
enforce this in the context of this class? Also it would have to cache multiple
instances of Field, because processing a single document may result in creating
multiple instances (at least one per pre-analyzed field, more if fields are
multi-valued).

Create a PreAnalyzedUpdateProcessor
---

Key: SOLR-4648
URL: https://issues.apache.org/jira/browse/SOLR-4648
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 4.3, 5.0
Reporter: Andrzej Bialecki
Assignee: Andrzej Bialecki
Fix For: 4.3, 5.0

Attachments: SOLR-4648.patch, SOLR-4648.patch, SOLR-4648.patch,
SOLR-4648.patch

Spin-off from the discussion in SOLR-4619.
Instead of using a PreAnalyzedField type we can use an UpdateRequestProcessor
that converts any input field values to StorableField-s, using the
PreAnalyzedParser-s, and then directly passes StorableField-s to
DocumentBuilder for indexing.

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

Re: [JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_17) - Build # 2714 - Failure!

2013-04-04 Thread Mark Miller


On Apr 3, 2013, at 7:18 PM, Chris Hostetter hossman_luc...@fucit.org wrote:

 : My other concern about that core reload is this:
 
 I'm not totally following what you are saying -- is there a bug open for 
 this to track it?  (I just filled another issue that concern me 
 related to this confFile update core reload situation, SOLR-4669, and i'm 
 wondering if we can fix two birds with one stone)

Let's say you have 3 nodes, a master, a repeater, and a slave.

When you do updates and commit on the master, things will replicate to the 
repeater. You now need to make the repeaters most replicatable commit the 
latest commit, even though a normal trigger for this (startup, commit) has not 
occurred. If you don't, the right stuff won't happen between the repeater and 
the slave.

In the non core reload case, we currently reach right in the ReplicationHandler 
and update the last replicatable commit point on the repeater as part of 
installing the new index. This is somewhat new, there used to be a commit that 
would push the slave gen past the leader by one. 

In the Core reload case, it's a little trickier. If you are replicating on 
startup, you should be fine - the right most replicatable commit will be set 
when the core reloads. But if you don't, and just have replicate on commit, the 
repeater won't be ready to replicate the right commit point to the slave.

I guess the best workaround for that at the moment is to be sure to have 
replicate on startup set on your repeater.

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

[jira] [Commented] (SOLR-4666) JSON Formating


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

nihed mbarek commented on SOLR-4666:


[~yo...@apache.org] The problem is related with Solr 4.0 

 JSON Formating
 --

 Key: SOLR-4666
 URL: https://issues.apache.org/jira/browse/SOLR-4666
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Linux server with Tomcat as application server 
Reporter: nihed mbarek
 Attachments: schema.xml


 Dear, 
 We discover that some fields (not multivalued) was formated as multivalued 
 for JSON output when on our schema we add : 
 bq.   ??dynamicField name=* type=ignored multiValued=true /??
 in other terms, an internal field like score will be displayed as : 
 bq. ??score:[2.9204934],??
 and not :
 bq. ??score:4.5376997,??
 there is no problem with xml output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3251) dynamically add field to schema


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

Erick Erickson commented on SOLR-3251:
--

Hmmm, There's already the possibility of sharing schemas, they're cached by 
path and time as I remember. And I'm also working on config sets as we speak. 
Any interactions here that spring to mind? I suppose I'll have to be looking at 
invalidating any shared config set if any of the underlying files change. I 
admit I haven't looked into the code at all, maybe this'll all be transparent 
to the config set caching layer but it'll be a good thing for me to be aware of 
when I get back to that JIRA (I've got some work done on it, not testable yet 
though).


 dynamically add field to schema
 ---

 Key: SOLR-3251
 URL: https://issues.apache.org/jira/browse/SOLR-3251
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
Assignee: Steve Rowe
 Attachments: SOLR-3251.patch, SOLR-3251.patch


 One related piece of functionality needed for SOLR-3250 is the ability to 
 dynamically add a field to the schema.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4670) Core mismatch in concurrent documents creation


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

Yonik Seeley commented on SOLR-4670:


How are you creating your cluster (i.e. what is the actual command used?)
How are you creating each core?

 Core mismatch in concurrent documents creation
 --

 Key: SOLR-4670
 URL: https://issues.apache.org/jira/browse/SOLR-4670
 Project: Solr
  Issue Type: Bug
  Components: multicore, SolrCloud
Affects Versions: 4.0, 4.1, 4.2
 Environment: CPU: 32x AMD Opteron(TM) Processor 6276
 RAM: 132073620 kB
 OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga)
 JDK 1.6.0_21
 JBoss [EAP] 4.3.0.GA_CP09
 Apache Solr 4.x
 Apache ZooKeeper 3.4.5
Reporter: Alberto Ferrini
  Labels: concurrency, multicore, solrcloud, zookeeper

 The issue can be reproduced in this way:
 - Install SolrCloud with at least 2 nodes
 - Install ZooKeeper with at least 2 nodes
 - Create 30 cores
 - After each core creation, create 20 random generated documents in a random 
 existent core with 2 concurrent threads on all solr nodes (for example, 
 document 1 in core 3 on node 1, document 2 in core 5 on node 1, document 3 in 
 core 3 on node 2, etc...).
 - After all cores creation, query each core for all documents and compare 
 insert data with query result
 Some documents result in different core than they are created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4874) Don't override non abstract methods in FilterAtomicReader and related classes


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

Robert Muir commented on LUCENE-4874:
-

i think attributes() should be overridden by the Filter** by default. This is 
basically a getter.

 Don't override non abstract methods in FilterAtomicReader and related classes
 -

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


 Terms.intersect is an optional method. The fact that it is overridden in 
 FilterTerms forces any non-trivial class that extends FilterTerms to override 
 intersect in order this method to have a correct behavior. If FilterTerms did 
 not override this method and used the default impl, we would not have this 
 problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Comment Edited] (SOLR-4670) Core mismatch in concurrent documents creation


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

Yonik Seeley edited comment on SOLR-4670 at 4/4/13 12:58 PM:
-

How are you creating your collection (i.e. what is the actual command used?)
How are you creating each core?

  was (Author: ysee...@gmail.com):
How are you creating your cluster (i.e. what is the actual command used?)
How are you creating each core?
  
 Core mismatch in concurrent documents creation
 --

 Key: SOLR-4670
 URL: https://issues.apache.org/jira/browse/SOLR-4670
 Project: Solr
  Issue Type: Bug
  Components: multicore, SolrCloud
Affects Versions: 4.0, 4.1, 4.2
 Environment: CPU: 32x AMD Opteron(TM) Processor 6276
 RAM: 132073620 kB
 OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga)
 JDK 1.6.0_21
 JBoss [EAP] 4.3.0.GA_CP09
 Apache Solr 4.x
 Apache ZooKeeper 3.4.5
Reporter: Alberto Ferrini
  Labels: concurrency, multicore, solrcloud, zookeeper

 The issue can be reproduced in this way:
 - Install SolrCloud with at least 2 nodes
 - Install ZooKeeper with at least 2 nodes
 - Create 30 cores
 - After each core creation, create 20 random generated documents in a random 
 existent core with 2 concurrent threads on all solr nodes (for example, 
 document 1 in core 3 on node 1, document 2 in core 5 on node 1, document 3 in 
 core 3 on node 2, etc...).
 - After all cores creation, query each core for all documents and compare 
 insert data with query result
 Some documents result in different core than they are created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: SOLR - 1093

2013-04-04 Thread Erick Erickson

Probably better to post on the lucene dev list, there's not much
action on this list.

Erick

On Tue, Apr 2, 2013 at 3:55 PM, Karthick Duraisamy Soundararaj
d.s.karth...@gmail.com wrote:
 Hello Committers,
  I had submitted a patch to the SOLR - 1093
 long back and I havent gotten any feedback on the same. [
 https://issues.apache.org/jira/browse/SOLR-1093 ]

 We have been using it in our company and the feature has been very useful. I
 see other people using it too. If someone can look at it and provide a
 feedback, it would be really helpful!

 Thank you,
 Karthick


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

[jira] [Commented] (LUCENE-3538) fix java7 warnings in the source code


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

Robert Muir commented on LUCENE-3538:
-

Hi Furkan, thanks for looking into this. I get a couple warnings when running 
the following commands with a java7 compiler:

I'm using 1.7.0_17

{noformat}
svn co https://svn.apache.org/repos/asf/lucene/dev/trunk
cd trunk/lucene
ant compile  ../compile.log
{noformat}

lucene/analysis/common module:
{noformat}
[javac] Compiling 360 source files to 
/home/rmuir/workspace/lucene-trunk/lucene/build/analysis/common/classes/java
[javac] 
/home/rmuir/workspace/lucene-trunk/lucene/analysis/common/src/java/org/tartarus/snowball/Among.java:46:
 warning: [rawtypes] found raw type: Class
[javac]   private static final Class?[] EMPTY_PARAMS = new Class[0];
[javac]  ^
[javac]   missing type arguments for generic class ClassT
[javac]   where T is a type-variable:
[javac] T extends Object declared in class Class
...

{noformat}

lucene/queries:
lots of warnings unfortunately
{noformat}
[javac]   missing type arguments for generic class MapK,V
[javac]   where K,V are type-variables:
[javac] K extends Object declared in interface Map
[javac] V extends Object declared in interface Map
[javac] 
/home/rmuir/workspace/lucene-trunk/lucene/queries/src/java/org/apache/lucene/queries/function/valuesource/QueryValueSource.java:54:
 warning: [rawtypes] found raw type: Map
[javac]   public FunctionValues getValues(Map fcontext, AtomicReaderContext 
readerContext) throws IOException {
{noformat}

lucene/queryparser:
again lots of warnings, some are in generated code which is more difficult, but 
also some silly ones, like:
{noformat}
[javac] 
/home/rmuir/workspace/lucene-trunk/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/GroupQueryNodeProcessor.java:54:
 warning: [dep-ann] deprecated item is not annotated with @Deprecated
[javac] public class GroupQueryNodeProcessor implements QueryNodeProcessor {
{noformat}

lucene/memory, lucene/highlighter, lucene/benchmark, and lucene/spatial also 
have warnings too.




 fix java7 warnings in the source code
 -

 Key: LUCENE-3538
 URL: https://issues.apache.org/jira/browse/LUCENE-3538
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
  Labels: newdev

 Now that oracle has fixed java7 bugs, I imagine some users will want to use 
 it.
 Currently if you compile lucene's code with java7 you get a ton of 
 warnings... lets clean this up

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4896) PostingsHighlighter should use a interface of PassageFormatter instead of a class


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

Robert Muir commented on LUCENE-4896:
-

[~survivant] Do you want to create a patch for this issue?

 PostingsHighlighter should use a interface of PassageFormatter instead of a 
 class
 -

 Key: LUCENE-4896
 URL: https://issues.apache.org/jira/browse/LUCENE-4896
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/highlighter
Affects Versions: 4.2
 Environment: NA
Reporter: Sebastien Dionne

 In my project I need a custom PassageFormatter to use with 
 PostingsHighlighter.  I extended PassageFormatter  to override format(...)
 but if I do that, I don't have access to the private variables.  So instead 
 of changing the scope to protected, it should be more usefull to use a 
 interface for PassageFormatter.
 like public DefaultPassageFormatter implements PassageFormatter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

New JIRA tagging Commit Bot

2013-04-04 Thread Mark Miller

I'm experimenting with an event driven commit bot today. It should mean much 
lower latency for tagging, and less room for accidentally tagging old commits. 
If today goes well, I'll look at setting things up on a more permanent basis.

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

[jira] [Commented] (LUCENE-4877) Fix analyzer factories to throw exception when arguments are invalid


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

Robert Muir commented on LUCENE-4877:
-

Thanks for cleaning this up Steve, much nicer.

I'd like to merge these commits back to 4.x if there are no objections.

 Fix analyzer factories to throw exception when arguments are invalid
 

 Key: LUCENE-4877
 URL: https://issues.apache.org/jira/browse/LUCENE-4877
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Reporter: Robert Muir
 Attachments: LUCENE-4877_one_solution_prototype.patch, 
 LUCENE-4877.patch, LUCENE-4877.patch, LUCENE-4877.patch, 
 LUCENE-4877-steve-minor-fixes.patch, 
 LUCENE-4877-steve-more-param-parsing-verbs.patch


 Currently if someone typos an argument someParamater=xyz instead of 
 someParameter=xyz, they get no exception and sometimes incorrect behavior.
 It would be way better if these factories threw exception on unknown params, 
 e.g. they removed the args they used and checked they were empty at the end.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4670) Core mismatch in concurrent documents creation

2013-04-04 Thread Alberto Ferrini (JIRA)


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

Alberto Ferrini commented on SOLR-4670:
---

I create a tree on ZooKeeper by {{SolrZkClient}} 
(org.apache.solr.common.cloud.SolrZkClient)
{quote}
{{SolrZkClient zkClient=new 
SolrZkClient(properties.getProperty(ZOOKEEPER_SERVER_ADDRESS), 
ZOOKEEPER_CLIENT_TIMEOUT);}}
{{String configName=request.getParameter(coreName);}}
{{File dir=new File(properties.getProperty(CORE_DIR));}}
{{uploadToZK(zkClient, dir, ZOOKEEPER_CONFIGS_ZKNODE + / + 
configName,configName);}}

The method {{uploadToZK}} invokes recursively {{zkClient.makePath()}}
{quote}

Then I send one request to each solr node for create the core by solrj client 
(org.apache.solr.client.solrj.impl.HttpSolrServer):

{quote}
{{String configName=request.getParameter(coreName);}}
{{HttpSolrServer solrServer=new HttpSolrServer(request.getParameter(url));}}
{{Create newCoreRequest=new Create();}}
{{newCoreRequest.setCollection(configName);}}
{{newCoreRequest.setDataDir(System.getProperty(solr.data.dir)+File.separator+configName);}}
{{newCoreRequest.setSchemaName(schema_\+configName\+.xml);}}
{{newCoreRequest.setConfigName(solrconfig_\+configName\+.xml);}}
{{newCoreRequest.setInstanceDir(configName+/);}}
{{newCoreRequest.setShardId(configName);}}
{{newCoreRequest.setCoreName(configName);
{{solrServer.request(newCoreRequest);}}
{quote}

At the end of the process, the line automatically added on each solr.xml is 
like this:
{quote}
{{core schema=schema_core_01.xml loadOnStartup=true shard=core_01 
instanceDir=core_01/ transient=false name=core_01 
config=solrconfig_core_01.xml collection=core_01 
dataDir=/home/solr/solr/server.2/data/core_01/}}
{quote}

 Core mismatch in concurrent documents creation
 --

 Key: SOLR-4670
 URL: https://issues.apache.org/jira/browse/SOLR-4670
 Project: Solr
  Issue Type: Bug
  Components: multicore, SolrCloud
Affects Versions: 4.0, 4.1, 4.2
 Environment: CPU: 32x AMD Opteron(TM) Processor 6276
 RAM: 132073620 kB
 OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga)
 JDK 1.6.0_21
 JBoss [EAP] 4.3.0.GA_CP09
 Apache Solr 4.x
 Apache ZooKeeper 3.4.5
Reporter: Alberto Ferrini
  Labels: concurrency, multicore, solrcloud, zookeeper

 The issue can be reproduced in this way:
 - Install SolrCloud with at least 2 nodes
 - Install ZooKeeper with at least 2 nodes
 - Create 30 cores
 - After each core creation, create 20 random generated documents in a random 
 existent core with 2 concurrent threads on all solr nodes (for example, 
 document 1 in core 3 on node 1, document 2 in core 5 on node 1, document 3 in 
 core 3 on node 2, etc...).
 - After all cores creation, query each core for all documents and compare 
 insert data with query result
 Some documents result in different core than they are created.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3755) shard splitting

2013-04-04 Thread Shalin Shekhar Mangar (JIRA)


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

Shalin Shekhar Mangar commented on SOLR-3755:
-

I ran into another bug. Adding mutable state in cloud descriptor (like shard 
state and range) is a bad idea.

The sub shard cores are created while the sub shard is in construction state 
therefore their cloud descriptor keeps construction as the shard state. If 
the sub shard leader goes down after the shard state has been changed to 
active, it sets the shard state to construction once again while publishing 
itself as down.

 shard splitting
 ---

 Key: SOLR-3755
 URL: https://issues.apache.org/jira/browse/SOLR-3755
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: SOLR-3755-combined.patch, 
 SOLR-3755-combinedWithReplication.patch, SOLR-3755-CoreAdmin.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, SOLR-3755.patch, 
 SOLR-3755-testSplitter.patch, SOLR-3755-testSplitter.patch


 We can currently easily add replicas to handle increases in query volume, but 
 we should also add a way to add additional shards dynamically by splitting 
 existing shards.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: [jira] [Commented] (SOLR-4381) Query-time multi-word synonym expansion

2013-04-04 Thread Erick Erickson

Does it work for you if you change the order of your filters; put the
synonym expansion after the stemming? But be very careful here, this
will also have consequences...

Best
Erick

On Thu, Apr 4, 2013 at 3:59 AM, Okke Klein (JIRA) j...@apache.org wrote:

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

Okke Klein commented on SOLR-4381:
--

Query-time multi-word synonym expansion
---

Attachments: SOLR-4381-2.patch, SOLR-4381.patch

This is an issue that seems to come up perennially.
The [Solr
docs|http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory]
caution that index-time synonym expansion should be preferred to query-time
synonym expansion, due to the way multi-word synonyms are treated and how
IDF values can be boosted artificially. But query-time expansion should have
huge benefits, given that changes to the synonyms don't require re-indexing,
the index size stays the same, and the IDF values for the documents don't
get permanently altered.
The proposed solution is to move the synonym expansion logic from the
analysis chain (either query- or index-type) and into a new QueryParser.
See the attached patch for an implementation.
The core Lucene functionality is untouched. Instead, the EDismaxQParser is
extended, and synonym expansion is done on-the-fly. Queries are parsed into
a lattice (i.e. all possible synonym combinations), while individual
components of the query are still handled by the EDismaxQParser itself.
It's not an ideal solution by any stretch. But it's nice and self-contained,
so it invites experimentation and improvement. And I think it fits in well
with the merry band of misfit query parsers, like {{func}} and {{frange}}.
More details about this solution can be found in [this blog
post|http://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/] and
[the Github page for the
code|https://github.com/healthonnet/hon-lucene-synonyms].
At the risk of tooting my own horn, I also think this patch sufficiently
fixes SOLR-3390 (highlighting problems with multi-word synonyms) and
LUCENE-4499 (better support for multi-word synonyms).

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

[jira] [Updated] (LUCENE-4902) Add a FilterDirectoryReader

2013-04-04 Thread Alan Woodward (JIRA)


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

Alan Woodward updated LUCENE-4902:
--

Attachment: LUCENE-4902.patch

Patch adds FilterDirectoryReader, and refactors AssertingDirectorReader to use 
it.

 Add a FilterDirectoryReader
 ---

 Key: LUCENE-4902
 URL: https://issues.apache.org/jira/browse/LUCENE-4902
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Attachments: LUCENE-4902.patch


 A FilterDirectoryReader would allow you to easily wrap all subreaders of a 
 DirectoryReader with FilterAtomicReaders.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LUCENE-4902) Add a FilterDirectoryReader

2013-04-04 Thread Alan Woodward (JIRA)

Alan Woodward created LUCENE-4902:
-

 Summary: Add a FilterDirectoryReader
 Key: LUCENE-4902
 URL: https://issues.apache.org/jira/browse/LUCENE-4902
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor


A FilterDirectoryReader would allow you to easily wrap all subreaders of a 
DirectoryReader with FilterAtomicReaders.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4899) FastVectorHighlihgter fails with SIOOB if single phrase or term is fragCharSize

2013-04-04 Thread Simon Willnauer (JIRA)


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

Simon Willnauer commented on LUCENE-4899:
-

anybody with more FVH knowledge up for a review?

 FastVectorHighlihgter fails with SIOOB if single phrase or term is  
 fragCharSize
 -

 Key: LUCENE-4899
 URL: https://issues.apache.org/jira/browse/LUCENE-4899
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.0, 4.1, 4.2, 3.6.2, 4.2.1
Reporter: Simon Willnauer
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4899.patch


 This has been reported on several occasions like SOLR-4660 /  SOLR-4137 or on 
 the ES mailing list 
 https://groups.google.com/d/msg/elasticsearch/IdyMSPK5gao/nKZq8_NYWmgJ
 The reason is that the current code expects the fragCharSize  matchLength 
 which is not necessarily true if you use phrases or if you have very long 
 terms like URLs or so. I have a test that reproduces the issue and a fix as 
 far as I can tell (me doesn't have much experience with the highlighter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4663) Log an error if more than one core points to the same data dir.

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

Erick Erickson updated SOLR-4663:
-

Attachment: SOLR-4663.patch

Here's a patch. It fixes another issue I saw with persisting (I'll be s
glad when that's obsoleted!).

It fails hard when either a core with a duplicate name is found or with a
duplicate data dir, both with old and new style solr.xml. It's still possible
for more than one core to share the same instance dir. I'd guess there are
other checks that could be done, but this is a start.

My real question is whether it's appropriate to fail hard on startup or just
log a very loud warning. Ryan's the only person who's weighed in on this so
far. My preference is to fail hard but I'm not particularly invested either way.

I'll be checking this in tomorrow at the latest unless there are objections.

Log an error if more than one core points to the same data dir.
---

Key: SOLR-4663
URL: https://issues.apache.org/jira/browse/SOLR-4663
Project: Solr
Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
Attachments: SOLR-4663.patch

In large multi-core setups, having mistakes whereby two or more cores point
to the same data dir seems quite possible. We should at least complain very
loudly in the logs if this is detected.
Should be a very straightforward check at core discovery time.
Is this serious enough to keep Solr from coming up at all?

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

[jira] [Commented] (SOLR-4347) Insure that newly-created cores via Admin handler are persisted in solr.xml


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

Erick Erickson commented on SOLR-4347:
--

I just verified that this still occurs in 4.x, I should have a patch up in a 
day or two.

 Insure that newly-created cores via Admin handler are persisted in solr.xml
 ---

 Key: SOLR-4347
 URL: https://issues.apache.org/jira/browse/SOLR-4347
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.1, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor

 From Andy, commenting on SOLR-4196 
 I noticed a bug in Solr-4.1 release that if there are unloaded transient 
 cores in solr.xml, and a new core is created via the admin handler, the 
 record of the core in solr.xml is removed on persist.
 Creating as a separate bug, I don't want to lose it, but I havent verified it 
 yet.
 Thanks for bringing this up Andy!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4663) Log an error if more than one core points to the same data dir.


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

Yonik Seeley commented on SOLR-4663:


Think about creating a core via API... pointing at another core's data 
directory should only only cause the create of that new core to fail.
Likewise, if someone messes with a core's configuration such that it fails on 
startup, it doesn't seem like this should stop the other correctly configured 
cores from loading.


 Log an error if more than one core points to the same data dir.
 ---

 Key: SOLR-4663
 URL: https://issues.apache.org/jira/browse/SOLR-4663
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-4663.patch


 In large multi-core setups, having mistakes whereby two or more cores point 
 to the same data dir seems quite possible. We should at least complain very 
 loudly in the logs if this is detected.
 Should be a very straightforward check at core discovery time.
 Is this serious enough to keep Solr from coming up at all?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LUCENE-4903) Add AssertingScorer

Adrien Grand created LUCENE-4903:


 Summary: Add AssertingScorer
 Key: LUCENE-4903
 URL: https://issues.apache.org/jira/browse/LUCENE-4903
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


I think we would benefit from having an AssertingScorer that would assert that 
scorers are advanced correctly, return valid scores (eg. not NaN), ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4897) Add a sugar API for traversing categories.


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

Michael McCandless commented on LUCENE-4897:


+1, thanks Shai!

 Add a sugar API for traversing categories.
 --

 Key: LUCENE-4897
 URL: https://issues.apache.org/jira/browse/LUCENE-4897
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Affects Versions: 4.2
Reporter: crocket
Priority: Trivial
  Labels: newdev
 Attachments: LUCENE-4897.patch, LUCENE-4897.patch


 Mike McCandless said in lucene-java-user mailing list.
 Maybe we could add some simple sugar APIs?
 Eg something like CollectionCategoryPath getChildren(int parentOrd)?
  (Or maybe it returns IteratorCategoryPath?)
 What about CollectionInteger getChildren(int parentOrd)?
 Integer would be more versatile and can easily be converted to CategoryPath 
 with TaxonomyReader.getPath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4666) JSON Formating


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

nihed mbarek commented on SOLR-4666:


I just made the test with Solr 4.2.1 and there is no problem with JSON

 JSON Formating
 --

 Key: SOLR-4666
 URL: https://issues.apache.org/jira/browse/SOLR-4666
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Linux server with Tomcat as application server 
Reporter: nihed mbarek
 Attachments: schema.xml


 Dear, 
 We discover that some fields (not multivalued) was formated as multivalued 
 for JSON output when on our schema we add : 
 bq.   ??dynamicField name=* type=ignored multiValued=true /??
 in other terms, an internal field like score will be displayed as : 
 bq. ??score:[2.9204934],??
 and not :
 bq. ??score:4.5376997,??
 there is no problem with xml output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4663) Log an error if more than one core points to the same data dir.

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

Erick Erickson commented on SOLR-4663:
--

bq: creating a core via API

This patch doesn't address this, at least not yet. Good point though, I'll see
about adding that in.

bq: If someone messes with a core's configuration such that it fails on
startup...

You always make my life more complicated G I can argue that either way,
is this a fail-fast situation or is the robustness of driving on as well as
possible worth the added difficulty in tracking down? The fast fix to the
current patch would be just to remove the offending cores from the lists of
cores (both lazily loaded and load-on-startup) and log an error.

This would imply that when someone tried to actually _do_ something with the
offending cores, they'd get a core not found message, which would be slightly
misleading, but there'd be a big fat error (not info, not warn) in the log
files so I'm not too worried. That would avoid the complexity of checking every
time we tried to open a core. The important bit is to fail without screwing up
the index files for the offending cores (two cores pointing to the same
dataDir). I expect that the current behavior for, say two cores with the same
name is that we use one or the other, perhaps not consistently. It's Not Right
to do anything at all IMO.

I think in the discovery case, though, the chance of copying the same
core.properties file to multiple places, thus having cores with the same name
or data dir is much more likely

So do you actively object to failing fast? Or are you ok with failing fast but
your comments are intended to make sure we're considering all the angles?
Initially I didn't want to make things more complicated, but by just _not_
putting the offending cores in the relevant lists I think the complexity
argument goes away and preserving index integrity is maintained so I'm +/-0.

Let me know...

Log an error if more than one core points to the same data dir.
---

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

[jira] [Commented] (LUCENE-4903) Add AssertingScorer


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

Michael McCandless commented on LUCENE-4903:


+1

It should also confirm that Weight.scoresDocsOutOfOrder didn't lie!

 Add AssertingScorer
 ---

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

 I think we would benefit from having an AssertingScorer that would assert 
 that scorers are advanced correctly, return valid scores (eg. not NaN), ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4671) CSV Formating

nihed mbarek created SOLR-4671:
--

 Summary: CSV Formating
 Key: SOLR-4671
 URL: https://issues.apache.org/jira/browse/SOLR-4671
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Server with Tomcat
Reporter: nihed mbarek


We just discover that we can't have alias for CSV Formating 
http://127.0.0.1:8983/solr/collection1/select?q=*%3A*fl=score%2C+idprod%3Aidwt=csvindent=true
using this schema 
https://issues.apache.org/jira/secure/attachment/12576952/schema.xml
for the standard core collection 


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4671) CSV Formating


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

nihed mbarek updated SOLR-4671:
---

Attachment: result.csv

 CSV Formating
 -

 Key: SOLR-4671
 URL: https://issues.apache.org/jira/browse/SOLR-4671
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Server with Tomcat
Reporter: nihed mbarek
 Attachments: result.csv


 We just discover that we can't have alias for CSV Formating 
 http://127.0.0.1:8983/solr/collection1/select?q=*%3A*fl=score%2C+idprod%3Aidwt=csvindent=true
 using this schema 
 https://issues.apache.org/jira/secure/attachment/12576952/schema.xml
 for the standard core collection 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4671) CSV Formating


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

nihed mbarek updated SOLR-4671:
---

Description: 
We just discover that we can't have alias for CSV Formating 
http://127.0.0.1:8983/solr/collection1/select?q=*%3A*fl=score%2C+idprod%3Aidwt=csvindent=true
using this schema 
https://issues.apache.org/jira/secure/attachment/12576952/schema.xml
for the standard core collection 
= result as attachment 


  was:
We just discover that we can't have alias for CSV Formating 
http://127.0.0.1:8983/solr/collection1/select?q=*%3A*fl=score%2C+idprod%3Aidwt=csvindent=true
using this schema 
https://issues.apache.org/jira/secure/attachment/12576952/schema.xml
for the standard core collection 



 CSV Formating
 -

 Key: SOLR-4671
 URL: https://issues.apache.org/jira/browse/SOLR-4671
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.2
 Environment: Linux Server with Tomcat
Reporter: nihed mbarek
 Attachments: result.csv


 We just discover that we can't have alias for CSV Formating 
 http://127.0.0.1:8983/solr/collection1/select?q=*%3A*fl=score%2C+idprod%3Aidwt=csvindent=true
 using this schema 
 https://issues.apache.org/jira/secure/attachment/12576952/schema.xml
 for the standard core collection 
 = result as attachment 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4903) Add AssertingScorer


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

Robert Muir commented on LUCENE-4903:
-

and score() etc shouldnt be called after these things return NO_MORE_DOCS.

 Add AssertingScorer
 ---

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

 I think we would benefit from having an AssertingScorer that would assert 
 that scorers are advanced correctly, return valid scores (eg. not NaN), ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4553) BasicDistributedZk2Test common failuire on jenkins cluster: status:404, message:Can not find: /onenodecollectioncore/update

2013-04-04 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-4553:
---

Turns out this happens on java 8 only it seems.

 BasicDistributedZk2Test common failuire on jenkins cluster: status:404, 
 message:Can not find: /onenodecollectioncore/update
 -

 Key: SOLR-4553
 URL: https://issues.apache.org/jira/browse/SOLR-4553
 Project: Solr
  Issue Type: Bug
  Components: Tests
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.3, 5.0




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4738) Killed JVM when first commit was running will generate a corrupted index

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

Michael McCandless updated LUCENE-4738:
---

Attachment: LUCENE-4738.patch

Patch, with test and fix.

The problem here was IndexFileDeleter was attempting to load the
initial commit point even though IndexWriter already detected that
there was no valid segments file. I just fixed IndexWriter to record
this, and pass a boolean telling IFD whehter it should open the
initial commit.

However, if you try to run CheckIndex, or open an IndexReader, on an
index in this state (corrupt initial commit) they will both fail,
since there is in fact no valid index.

Killed JVM when first commit was running will generate a corrupted index

Key: LUCENE-4738
URL: https://issues.apache.org/jira/browse/LUCENE-4738
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.0
Environment: OS: Linux 2.6.32-220.23.1.el6.x86_64
Java: java version 1.7.0_05
Lucene: lucene-core-4.0.0
Reporter: Billow Gao
Attachments: LUCENE-4738.patch, LUCENE-4738_test.patch

1. Start a NEW IndexWriterBuilder on an empty folder,
add some documents to the index
2. Call commit
3. When the segments_1 file with 0 byte was created, kill the JVM
We will end with a corrupted index with an empty segments_1.
We only have issue with the first commit crash.
Also, if you tried to open an IndexSearcher on a new index. And the first
commit on the index was not finished yet. Then you will see exception like:
===
org.apache.lucene.index.IndexNotFoundException: no segments* file found in
org.apache.lucene.store.MMapDirectory@C:\tmp\testdir
lockFactory=org.apache.lucene.store.NativeFSLockFactory@6ee00df: files:
[write.lock, _0.fdt, _0.fdx]
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:741)
at
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:52)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:65)
===
So when a new index was created, we should first create an empty index. We
should not wait for the commit/close call to create the segment file.
If we had an empty index there. It won't leave a corrupted index when there
were a power issue on the first commit.
And a concurrent IndexSearcher can access to the index(No match is better
than exception).

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

[jira] [Comment Edited] (LUCENE-3538) fix java7 warnings in the source code

2013-04-04 Thread Furkan KAMACI (JIRA)


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

Furkan KAMACI edited comment on LUCENE-3538 at 4/4/13 3:33 PM:
---

I use Java(TM) SE Runtime Environment (build 1.7.0_17-b02) ,Apache Ant(TM) 
version 1.9.0, Apache Ivy 2.3.0 on Centos 6.4 64 bit Linux.

Everything is OK and there is no warning. These are the just things except for 
usual build logs:

At ant compile step under lucene-solr folder, at ant compile step under 
lucene-solr/lucene folder, at ant dist step under lucene-solr/lucene folder:

{code}
jflex-uptodate-check:

jflex-notice:
 [echo] 
 [echo]   One or more of the JFlex .jflex files is newer than its 
corresponding
 [echo]   .java file.  Run the jflex target to regenerate the 
artifacts.
 [echo]
{code}

The only warnings that I get at ant dist step under lucene-solr/lucene folder:

{code}
download-java6-javadoc-packagelist:
   [delete] Deleting: 
/home/kamaci/lucene-solr/lucene/build/docs/analyzers-kuromoji/stylesheet.css
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.analysis.ja...
  [javadoc] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.ja.dict...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.ja.tokenattributes...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.ja.util...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.7.0_17
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/home/kamaci/lucene-solr/lucene/build/docs/analyzers-kuromoji/help-doc.html...
  [javadoc] Note: Custom tags that were not seen:  @lucene.internal
  [javadoc] 1 warning
  [jar] Building jar: 
/home/kamaci/lucene-solr/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-4.2.1-SNAPSHOT-javadoc.jar
 [echo] Building analyzers-morfologik...
{code}

and the other one:

{code}
download-java6-javadoc-packagelist:
   [delete] Deleting: 
/home/kamaci/lucene-solr/lucene/build/docs/analyzers-morfologik/stylesheet.css
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.morfologik...
  [javadoc] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.7.0_17
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/home/kamaci/lucene-solr/lucene/build/docs/analyzers-morfologik/help-doc.html...
  [javadoc] Note: Custom tags that were not seen:  @lucene.internal, 
@lucene.experimental
  [javadoc] 1 warning
  [jar] Building jar: 
/home/kamaci/lucene-solr/lucene/build/analysis/morfologik/lucene-analyzers-morfologik-4.2.1-SNAPSHOT-javadoc.jar
 [echo] Building analyzers-phonetic...
{code}

and all other warnings are same with below ones. 

I don't get any other warnings. This issue is created nearly two years ago. Is 
there anybody who gets warning at compile step of project? Otherwise you can 
assign it to me.

  was (Author: kamaci):
I use Java(TM) SE Runtime Environment (build 1.7.0_17-b02) ,Apache Ant(TM) 
version 1.9.0, Apache Ivy 2.3.0 on Centos 6.4 64 bit Linux.

Everything is OK and there is no warning. These are the just things except for 
usual build logs:

At ant compile step under lucene-solr folder, at ant compile step under 
lucene-solr/lucene folder, at ant dist step under lucene-solr/lucene folder:

jflex-uptodate-check:

jflex-notice:
 [echo] 
 [echo]   One or more of the JFlex .jflex files is newer than its 
corresponding
 [echo]   .java file.  Run the jflex target to regenerate the 
artifacts.
 [echo]

The only warnings that I get at ant dist step under lucene-solr/lucene folder:

download-java6-javadoc-packagelist:
   [delete] Deleting: 
/home/kamaci/lucene-solr/lucene/build/docs/analyzers-kuromoji/stylesheet.css
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.analysis.ja...
  [javadoc] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.ja.dict...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.ja.tokenattributes...
  [javadoc] Loading source files for package 
org.apache.lucene.analysis.ja.util...

[jira] [Commented] (LUCENE-3538) fix java7 warnings in the source code

2013-04-04 Thread Furkan KAMACI (JIRA)


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

Furkan KAMACI commented on LUCENE-3538:
---

Robert could you add your environment features (OS, etc.) because I don't get 
such kind of warnings. Maybe I can reproduce that warnings and so resolve them.

 fix java7 warnings in the source code
 -

 Key: LUCENE-3538
 URL: https://issues.apache.org/jira/browse/LUCENE-3538
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
  Labels: newdev

 Now that oracle has fixed java7 bugs, I imagine some users will want to use 
 it.
 Currently if you compile lucene's code with java7 you get a ton of 
 warnings... lets clean this up

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-3538) fix java7 warnings in the source code


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

Robert Muir commented on LUCENE-3538:
-

sure, my configuration is very similar to yours:

Linux beast 3.5.0-23-generic #35-Ubuntu SMP Thu Jan 24 13:15:40 UTC 2013 x86_64 
x86_64 x86_64 GNU/Linux
java version 1.7.0_17
Java(TM) SE Runtime Environment (build 1.7.0_17-b02)
Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode)
Apache Ant(TM) version 1.8.2 compiled on December 20 2010



 fix java7 warnings in the source code
 -

 Key: LUCENE-3538
 URL: https://issues.apache.org/jira/browse/LUCENE-3538
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
  Labels: newdev

 Now that oracle has fixed java7 bugs, I imagine some users will want to use 
 it.
 Currently if you compile lucene's code with java7 you get a ton of 
 warnings... lets clean this up

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (SOLR-4666) JSON Formating


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

Yonik Seeley resolved SOLR-4666.


Resolution: Fixed

I found the original JIRA issue (SOLR-4036)... this was indeed fixed in 4.1
Thanks for verifying!

 JSON Formating
 --

 Key: SOLR-4666
 URL: https://issues.apache.org/jira/browse/SOLR-4666
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: Linux server with Tomcat as application server 
Reporter: nihed mbarek
 Attachments: schema.xml


 Dear, 
 We discover that some fields (not multivalued) was formated as multivalued 
 for JSON output when on our schema we add : 
 bq.   ??dynamicField name=* type=ignored multiValued=true /??
 in other terms, an internal field like score will be displayed as : 
 bq. ??score:[2.9204934],??
 and not :
 bq. ??score:4.5376997,??
 there is no problem with xml output.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4899) FastVectorHighlihgter fails with SIOOB if single phrase or term is fragCharSize

2013-04-04 Thread Koji Sekiguchi (JIRA)


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

Koji Sekiguchi commented on LUCENE-4899:


Looks good, Simon!

 FastVectorHighlihgter fails with SIOOB if single phrase or term is  
 fragCharSize
 -

 Key: LUCENE-4899
 URL: https://issues.apache.org/jira/browse/LUCENE-4899
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.0, 4.1, 4.2, 3.6.2, 4.2.1
Reporter: Simon Willnauer
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4899.patch


 This has been reported on several occasions like SOLR-4660 /  SOLR-4137 or on 
 the ES mailing list 
 https://groups.google.com/d/msg/elasticsearch/IdyMSPK5gao/nKZq8_NYWmgJ
 The reason is that the current code expects the fragCharSize  matchLength 
 which is not necessarily true if you use phrases or if you have very long 
 terms like URLs or so. I have a test that reproduces the issue and a fix as 
 far as I can tell (me doesn't have much experience with the highlighter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4903) Add AssertingScorer


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

Adrien Grand commented on LUCENE-4903:
--

bq. It should also confirm that Weight.scoresDocsOutOfOrder didn't lie!

How can I check for that?

 Add AssertingScorer
 ---

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

 I think we would benefit from having an AssertingScorer that would assert 
 that scorers are advanced correctly, return valid scores (eg. not NaN), ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4903) Add AssertingScorer


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

Michael McCandless commented on LUCENE-4903:


bq. How can I check for that?

Well, hopefully we have an AssertingWeight, and then when its scorer() method 
is returned, it calls .scoresDocsOOO on the wrapped weight, and if that returns 
true, then the returned AssertingScorer should ensure every returned docID is  
the previous one, I think?

 Add AssertingScorer
 ---

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

 I think we would benefit from having an AssertingScorer that would assert 
 that scorers are advanced correctly, return valid scores (eg. not NaN), ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4858) Early termination with SortingMergePolicy


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

Adrien Grand commented on LUCENE-4858:
--

Thanks Shai, storing the Sorter is a good step forward to avoid traps. Now that 
SORTER_ID_PROP is added to the diagnostics, maybe that SORTED_DIAGNOSTICS_PROP 
is redundant?

I would like that we make the collector more robust too. Nothing prevent you 
from wrapping eg. a TotalHitCountCollector inside it. I've been thinking about 
adding an optional operation to Sorter that returns a oal.search.Sort that 
describes the index order so that we could hide all the early-termination 
complexity behind a custom IndexSearcher that could never return wrong results. 
This would make the API accessible to casual users while super-expert users 
could still write custom collectors if they need approximate results. But maybe 
we don't even need to provide an expert API given how straightforward it is to 
detect if the segment is sorted and to terminate the collection on a segment. 
What do you think?

I'll work on improving documentation as well.

 Early termination with SortingMergePolicy
 -

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

 Attachments: LUCENE-4858.patch, LUCENE-4858.patch, LUCENE-4858.patch


 Spin-off of LUCENE-4752, see 
 https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13606565page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13606565
  and 
 https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13607282page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13607282
 When an index is sorted per-segment, queries that sort according to the index 
 sort order could be early terminated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LUCENE-4904) Sorter API: Make NumericDocValuesSorter able to sort in reverse order

Adrien Grand created LUCENE-4904:


 Summary: Sorter API: Make NumericDocValuesSorter able to sort in 
reverse order
 Key: LUCENE-4904
 URL: https://issues.apache.org/jira/browse/LUCENE-4904
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Trivial
 Fix For: 4.3


Today it is only able to sort in ascending order.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LUCENE-4905) make maxPassages per-field in postingshighlighter

Robert Muir created LUCENE-4905:
---

 Summary: make maxPassages per-field in postingshighlighter
 Key: LUCENE-4905
 URL: https://issues.apache.org/jira/browse/LUCENE-4905
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir
 Attachments: LUCENE-4905.patch

in case you e.g. want smaller summarizes for a bunch of little fields and then 
a bit bigger one for the body field and so on.

We can do this by only changing the 'expert' methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4905) make maxPassages per-field in postingshighlighter


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

Robert Muir updated LUCENE-4905:


Attachment: LUCENE-4905.patch

 make maxPassages per-field in postingshighlighter
 -

 Key: LUCENE-4905
 URL: https://issues.apache.org/jira/browse/LUCENE-4905
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir
 Attachments: LUCENE-4905.patch


 in case you e.g. want smaller summarizes for a bunch of little fields and 
 then a bit bigger one for the body field and so on.
 We can do this by only changing the 'expert' methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4663) Log an error if more than one core points to the same data dir.

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

Hoss Man commented on SOLR-4663:

bq. ... The fast fix to the current patch would be just to remove the offending
cores from the lists of cores (both lazily loaded and load-on-startup) and log
an error.

bq. This would imply that when someone tried to actually do something with the
offending cores, they'd get a core not found message, which would be slightly
misleading, but there'd be a big fat error (not info, not warn) in the log
files so I'm not too worried. ...

Don't forget that CoreContainer now has the ability to track and report (as
part of STATUS requests) that cores failed to initialize (either on startup
or via API calls) and why. (see SOLR-3591 and child tasks)

This type of dataDir error should be no different: if coreA loads fine, and
then coreB fails to load because it points at the same data dir as coreA that
doesn't need to prevent the server from functioning, coreA should still be
usable, and as long as the error is properly recorded in the CoreContainer the
UI and the CoreAdminHandler will report back why coreB isn't available.

Log an error if more than one core points to the same data dir.
---

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

[jira] [Commented] (LUCENE-4905) make maxPassages per-field in postingshighlighter


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

Michael McCandless commented on LUCENE-4905:


+1

Everything-per-field ...

 make maxPassages per-field in postingshighlighter
 -

 Key: LUCENE-4905
 URL: https://issues.apache.org/jira/browse/LUCENE-4905
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir
 Attachments: LUCENE-4905.patch


 in case you e.g. want smaller summarizes for a bunch of little fields and 
 then a bit bigger one for the body field and so on.
 We can do this by only changing the 'expert' methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LUCENE-4906) PostingsHighlighter's PassageFormatter should allow for rendering to arbitrary objects

Michael McCandless created LUCENE-4906:
--

 Summary: PostingsHighlighter's PassageFormatter should allow for 
rendering to arbitrary objects
 Key: LUCENE-4906
 URL: https://issues.apache.org/jira/browse/LUCENE-4906
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless


For example, in a server, I may want to render the highlight result to 
JsonObject to send back to the front-end. Today since we render to string, I 
have to render to JSON string and then re-parse to JsonObject, which is 
inefficient...

Or, if (Rob's idea:) we make a query that's like MoreLikeThis but it pulls 
terms from snippets instead, so you get proximity-influenced salient/expanded 
terms, then perhaps that renders to just an array of tokens or fragments or 
something from each snippet.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4672) requests for cores which had known startup init failures should result in 500 not 404

Hoss Man created SOLR-4672:
--

 Summary: requests for cores which had known startup init failures 
should result in 500 not 404
 Key: SOLR-4672
 URL: https://issues.apache.org/jira/browse/SOLR-4672
 Project: Solr
  Issue Type: Improvement
Reporter: Hoss Man


SOLR-3591 added support for tracking if a core failed to init properly, and 
reporting this data back in STATUS request to the CoreAdminHandler so they 
could be displayed in the UI.

Attempts to use those cores anyway (for queries or updates, etc...) by 
users/clients that may not realize the core failed to init results in 404 
errors because the core doesn't exist, however it should be fairly straight 
forward to intead return a 500 error wrapping the cause of the init failure.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4663) Log an error if more than one core points to the same data dir.


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

Erick Erickson commented on SOLR-4663:
--

~hossman Didn't know that, that sounds like it pretty much solves the issue. 
I'll look over the patch, but any tips on what properly recorded means (I 
have to run out now, so I'm being lazy, but I can look later.

Erick

 Log an error if more than one core points to the same data dir.
 ---

 Key: SOLR-4663
 URL: https://issues.apache.org/jira/browse/SOLR-4663
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.3, 5.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Priority: Minor
 Attachments: SOLR-4663.patch


 In large multi-core setups, having mistakes whereby two or more cores point 
 to the same data dir seems quite possible. We should at least complain very 
 loudly in the logs if this is detected.
 Should be a very straightforward check at core discovery time.
 Is this serious enough to keep Solr from coming up at all?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4663) Log an error if more than one core points to the same data dir.

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

Hoss Man commented on SOLR-4663:

Minor Tangent...

bq. ...This would imply that when someone tried to actually do something with
the offending cores, they'd get a core not found message,...

After posting my last comment, it occured to me that even though we are
tracking core init failures and reporting them in STATUS requests, we are still
returning 404s when people attempt to use those cores ... i've opened SOLR-4672
to consier returning a 500 wraped around the init error.

Log an error if more than one core points to the same data dir.
---

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

[jira] [Created] (SOLR-4673) semanticsMode consistency acts like classic-consistency-hybrid

2013-04-04 Thread Sam Kass (JIRA)

Sam Kass created SOLR-4673:
--

 Summary: semanticsMode consistency acts like 
classic-consistency-hybrid
 Key: SOLR-4673
 URL: https://issues.apache.org/jira/browse/SOLR-4673
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.1
Reporter: Sam Kass


Code like the following, run with semanticsMode set to consistency, should 
fail on the second doc.  Instead, it's acting like classic-consistency-hybrid, 
where it treats the second doc as if it should always overwrite.  (Going by 
docs in http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics as it's 
the only place where this feature added 2 releases ago is as yet documented.)

{quote}
String id = UUID.randomUUID().toString();
SolrInputDocument docA = new SolrInputDocument();
docA.addField(id, id);
docA.addField(_version_, -1);
SolrInputDocument docB = new SolrInputDocument();
docB.addField(id, id);
// intentionally omit _version_
solrServer.add(docA);
solrServer.add(docB);
{quote}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4674) repeaters must be configured to replicate on startup in order to work properly when replicating config files

Hoss Man created SOLR-4674:
--

 Summary: repeaters must be configured to replicate on startup in 
order to work properly when replicating config files
 Key: SOLR-4674
 URL: https://issues.apache.org/jira/browse/SOLR-4674
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller


Filing on Mark's behalf based on a mailing list thread about replication tests 
related to automatic core reloads...

{quote}
Let's say you have 3 nodes, a master, a repeater, and a slave.

When you do updates and commit on the master, things will replicate to the 
repeater. You now need to make the repeaters most replicatable commit the 
latest commit, even though a normal trigger for this (startup, commit) has not 
occurred. If you don't, the right stuff won't happen between the repeater and 
the slave.

In the non core reload case, we currently reach right in the ReplicationHandler 
and update the last replicatable commit point on the repeater as part of 
installing the new index. This is somewhat new, there used to be a commit that 
would push the slave gen past the leader by one. 

In the Core reload case, it's a little trickier. If you are replicating on 
startup, you should be fine - the right most replicatable commit will be set 
when the core reloads. But if you don't, and just have replicate on commit, the 
repeater won't be ready to replicate the right commit point to the slave.

I guess the best workaround for that at the moment is to be sure to have 
replicate on startup set on your repeater.


{quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4675) improve PostingsHighlighter integration

Robert Muir created SOLR-4675:
-

 Summary: improve PostingsHighlighter integration
 Key: SOLR-4675
 URL: https://issues.apache.org/jira/browse/SOLR-4675
 Project: Solr
  Issue Type: Improvement
Reporter: Robert Muir
Assignee: Robert Muir


currently the integration started out very simple (as custom highlighter class 
with minimal options, mostly not query-time or per-field).

But recently we made this a lot more flexible in lucene (e.g. added various 
per-field options), so i'd like to add a better/more powerful mapping to more 
of the existing highlighting parameters.

I still plan to keep it a custom highlighter rather than tossed into the crazy 
bipolar DefaultSolrHighlighter mess, but this will make it easier to use.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LUCENE-4907) Tokenizer

2013-04-04 Thread luciano aparecido dos santos (JIRA)

luciano aparecido dos santos created LUCENE-4907:


 Summary: Tokenizer
 Key: LUCENE-4907
 URL: https://issues.apache.org/jira/browse/LUCENE-4907
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
 Environment: WINDOWS 7, NETBEANS 7.2.1
Reporter: luciano aparecido dos santos


Hi,

I'm trying to remove the accents in the search, find words removing special 
characters such as accents (ANDRÉ equals ANDRE).
I found the class ICUTokenizer but got the Exception in thread main 
java.lang.NoSuchMethodError: 
com.ibm.icu.text.UnicodeSet.freeze()Lcom/ibm/icu/text/UnicodeSet;
at 
org.apache.lucene.analysis.icu.segmentation.LaoBreakIterator.clinit(LaoBreakIterator.java:73)
at 
org.apache.lucene.analysis.icu.segmentation.DefaultICUTokenizerConfig.clinit(DefaultICUTokenizerConfig.java:73)


  Somebody can help me?

Page ref.: http://lucene.apache.org/core/4_2_0/analyzers-icu/index.html



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-3538) fix java7 warnings in the source code

2013-04-04 Thread Uwe Schindler (JIRA)


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

Uwe Schindler commented on LUCENE-3538:
---

Furken: You need to do ant clean from the root level first, because javac 
only shows warnings when classes are actually compiled. If you run ant a second 
time afterwards, no warnings will be displayed ad javac no longer compiles any 
classes (because the .class files are up-to-date).

 fix java7 warnings in the source code
 -

 Key: LUCENE-3538
 URL: https://issues.apache.org/jira/browse/LUCENE-3538
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
  Labels: newdev

 Now that oracle has fixed java7 bugs, I imagine some users will want to use 
 it.
 Currently if you compile lucene's code with java7 you get a ton of 
 warnings... lets clean this up

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Welcome Shalin Shekhar Mangar to the PMC

2013-04-04 Thread Steve Rowe

I'm pleased to announce that Shalin Shekhar Mangar has accepted the PMC's 
invitation to join.

Welcome Shalin!

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

[jira] [Commented] (SOLR-4648) Create a PreAnalyzedUpdateProcessor

2013-04-04 Thread David Smiley (JIRA)


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

David Smiley commented on SOLR-4648:


I like how your refactoring has clarified the logic in the URP.  And I like 
your new PreAnalyzedUpdateProcessorFactory.createFieldType() method.

I think you're right that sharing Field instances isn't such a good idea after 
all.

* minor: in the URP, for (Object o : src.getValues()) { can be for (Object o 
: src) {  since it implements Iterable, and for the single-value case avoids 
redundant collection wrapping.

The remaining thing I'm thinking of is wether 
PreAnalyzedUpdateProcessorFactory.createFieldType() should move down into 
Solr's FieldType where it can be re-used so we don't duplicate this code.  
Seems pretty clear this is a good idea.  Then, I'm wondering if these Lucene 
FieldType instances could be cached on Solr's SchemaField so that they don't 
have to be needlessly re-created for each indexed value that runs through Solr. 
 The only obstacle I see to this is that getIndexOptions(field,val) takes the 
value, and if that value were to alter the logic then the FieldType can't be 
shared.  This is a protected method and I don't see anything that overrides it, 
and the default implementation doesn't use the value.  I'll create another 
issue for that; I can get off track easily and try to fix the world in one 
issue :-)

 Create a PreAnalyzedUpdateProcessor
 ---

 Key: SOLR-4648
 URL: https://issues.apache.org/jira/browse/SOLR-4648
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.3, 5.0
Reporter: Andrzej Bialecki 
Assignee: Andrzej Bialecki 
 Fix For: 4.3, 5.0

 Attachments: SOLR-4648.patch, SOLR-4648.patch, SOLR-4648.patch, 
 SOLR-4648.patch


 Spin-off from the discussion in SOLR-4619.
 Instead of using a PreAnalyzedField type we can use an UpdateRequestProcessor 
 that converts any input field values to StorableField-s, using the 
 PreAnalyzedParser-s, and then directly passes StorableField-s to 
 DocumentBuilder for indexing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-4907) Tokenizer


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

Shawn Heisey resolved LUCENE-4907.
--

Resolution: Not A Problem

To use the ICU analysis components, you need two extra jars in your classpath.  
For 4.2.0, these are:

icu4j-49.1.jar
lucene-analyzers-icu-4.2.0.jar

You should be able to find these in your binary download or when you build from 
source.  For the lucene binary download, they are in analysis/icu.  For the 
solr binary download, they are in contrib/analysis-extras.


 Tokenizer
 -

 Key: LUCENE-4907
 URL: https://issues.apache.org/jira/browse/LUCENE-4907
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
 Environment: WINDOWS 7, NETBEANS 7.2.1
Reporter: luciano aparecido dos santos

 Hi,
 I'm trying to remove the accents in the search, find words removing 
 special characters such as accents (ANDRÉ equals ANDRE).
 I found the class ICUTokenizer but got the Exception in thread main 
 java.lang.NoSuchMethodError: 
 com.ibm.icu.text.UnicodeSet.freeze()Lcom/ibm/icu/text/UnicodeSet;
   at 
 org.apache.lucene.analysis.icu.segmentation.LaoBreakIterator.clinit(LaoBreakIterator.java:73)
   at 
 org.apache.lucene.analysis.icu.segmentation.DefaultICUTokenizerConfig.clinit(DefaultICUTokenizerConfig.java:73)
   Somebody can help me?
 Page ref.: http://lucene.apache.org/core/4_2_0/analyzers-icu/index.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Issue Comment Deleted] (LUCENE-4907) Tokenizer


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

Shawn Heisey updated LUCENE-4907:
-

Comment: was deleted

(was: To use the ICU analysis components, you need two extra jars in your 
classpath.  For 4.2.0, these are:

icu4j-49.1.jar
lucene-analyzers-icu-4.2.0.jar

You should be able to find these in your binary download or when you build from 
source.  For the lucene binary download, they are in analysis/icu.  For the 
solr binary download, they are in contrib/analysis-extras.
)

 Tokenizer
 -

 Key: LUCENE-4907
 URL: https://issues.apache.org/jira/browse/LUCENE-4907
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
 Environment: WINDOWS 7, NETBEANS 7.2.1
Reporter: luciano aparecido dos santos

 Hi,
 I'm trying to remove the accents in the search, find words removing 
 special characters such as accents (ANDRÉ equals ANDRE).
 I found the class ICUTokenizer but got the Exception in thread main 
 java.lang.NoSuchMethodError: 
 com.ibm.icu.text.UnicodeSet.freeze()Lcom/ibm/icu/text/UnicodeSet;
   at 
 org.apache.lucene.analysis.icu.segmentation.LaoBreakIterator.clinit(LaoBreakIterator.java:73)
   at 
 org.apache.lucene.analysis.icu.segmentation.DefaultICUTokenizerConfig.clinit(DefaultICUTokenizerConfig.java:73)
   Somebody can help me?
 Page ref.: http://lucene.apache.org/core/4_2_0/analyzers-icu/index.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Reopened] (LUCENE-4907) Tokenizer


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

Shawn Heisey reopened LUCENE-4907:
--


 Tokenizer
 -

 Key: LUCENE-4907
 URL: https://issues.apache.org/jira/browse/LUCENE-4907
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
 Environment: WINDOWS 7, NETBEANS 7.2.1
Reporter: luciano aparecido dos santos

 Hi,
 I'm trying to remove the accents in the search, find words removing 
 special characters such as accents (ANDRÉ equals ANDRE).
 I found the class ICUTokenizer but got the Exception in thread main 
 java.lang.NoSuchMethodError: 
 com.ibm.icu.text.UnicodeSet.freeze()Lcom/ibm/icu/text/UnicodeSet;
   at 
 org.apache.lucene.analysis.icu.segmentation.LaoBreakIterator.clinit(LaoBreakIterator.java:73)
   at 
 org.apache.lucene.analysis.icu.segmentation.DefaultICUTokenizerConfig.clinit(DefaultICUTokenizerConfig.java:73)
   Somebody can help me?
 Page ref.: http://lucene.apache.org/core/4_2_0/analyzers-icu/index.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4907) Tokenizer


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

Shawn Heisey commented on LUCENE-4907:
--

Closing the issue was a mistake, I should have read more carefully before 
acting.

 Tokenizer
 -

 Key: LUCENE-4907
 URL: https://issues.apache.org/jira/browse/LUCENE-4907
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
 Environment: WINDOWS 7, NETBEANS 7.2.1
Reporter: luciano aparecido dos santos

 Hi,
 I'm trying to remove the accents in the search, find words removing 
 special characters such as accents (ANDRÉ equals ANDRE).
 I found the class ICUTokenizer but got the Exception in thread main 
 java.lang.NoSuchMethodError: 
 com.ibm.icu.text.UnicodeSet.freeze()Lcom/ibm/icu/text/UnicodeSet;
   at 
 org.apache.lucene.analysis.icu.segmentation.LaoBreakIterator.clinit(LaoBreakIterator.java:73)
   at 
 org.apache.lucene.analysis.icu.segmentation.DefaultICUTokenizerConfig.clinit(DefaultICUTokenizerConfig.java:73)
   Somebody can help me?
 Page ref.: http://lucene.apache.org/core/4_2_0/analyzers-icu/index.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (SOLR-4676) Share a Lucene FieldType instance instead of creating on each call to createField()

2013-04-04 Thread David Smiley (JIRA)

David Smiley created SOLR-4676:
--

 Summary: Share a Lucene FieldType instance instead of creating on 
each call to createField()
 Key: SOLR-4676
 URL: https://issues.apache.org/jira/browse/SOLR-4676
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: David Smiley
Assignee: David Smiley
Priority: Minor


I think the Lucene FieldType instances should be cached on Solr's SchemaField 
so that they don't have to be needlessly re-created for each indexed value that 
runs through Solr in SchemaField.createField(). The only obstacle I see to this 
is that getIndexOptions(field,val) takes the value, and if that value were to 
alter the logic then the FieldType can't be shared. This is a protected method 
and I don't see anything that overrides it, and the default implementation 
doesn't use the value. So I think it can be removed.  Patch in progress...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: Welcome Shalin Shekhar Mangar to the PMC

2013-04-04 Thread Adrien Grand

Welcome Shalin!

--
Adrien

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

[jira] [Comment Edited] (LUCENE-4907) Tokenizer


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

Shawn Heisey edited comment on LUCENE-4907 at 4/4/13 6:37 PM:
--

It looks like you do have the lucene-analyzers-icu-4.2.0.jar file, but do you 
also have the icu4j-49.1.jar file in your classpath?  The method that it says 
is missing appears to be from that jar file.

This should have been brought up on the mailing list first.  If it turns out 
that you do have a real bug, then filing an issue is appropriate.


  was (Author: elyograg):
Closing the issue was a mistake, I should have read more carefully before 
acting.
  
 Tokenizer
 -

 Key: LUCENE-4907
 URL: https://issues.apache.org/jira/browse/LUCENE-4907
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
 Environment: WINDOWS 7, NETBEANS 7.2.1
Reporter: luciano aparecido dos santos

 Hi,
 I'm trying to remove the accents in the search, find words removing 
 special characters such as accents (ANDRÉ equals ANDRE).
 I found the class ICUTokenizer but got the Exception in thread main 
 java.lang.NoSuchMethodError: 
 com.ibm.icu.text.UnicodeSet.freeze()Lcom/ibm/icu/text/UnicodeSet;
   at 
 org.apache.lucene.analysis.icu.segmentation.LaoBreakIterator.clinit(LaoBreakIterator.java:73)
   at 
 org.apache.lucene.analysis.icu.segmentation.DefaultICUTokenizerConfig.clinit(DefaultICUTokenizerConfig.java:73)
   Somebody can help me?
 Page ref.: http://lucene.apache.org/core/4_2_0/analyzers-icu/index.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4907) Tokenizer

2013-04-04 Thread luciano aparecido dos santos (JIRA)


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

luciano aparecido dos santos commented on LUCENE-4907:
--

Shawn, I have these jars on classpath. I still keep getting the same error.

 Tokenizer
 -

 Key: LUCENE-4907
 URL: https://issues.apache.org/jira/browse/LUCENE-4907
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
 Environment: WINDOWS 7, NETBEANS 7.2.1
Reporter: luciano aparecido dos santos

 Hi,
 I'm trying to remove the accents in the search, find words removing 
 special characters such as accents (ANDRÉ equals ANDRE).
 I found the class ICUTokenizer but got the Exception in thread main 
 java.lang.NoSuchMethodError: 
 com.ibm.icu.text.UnicodeSet.freeze()Lcom/ibm/icu/text/UnicodeSet;
   at 
 org.apache.lucene.analysis.icu.segmentation.LaoBreakIterator.clinit(LaoBreakIterator.java:73)
   at 
 org.apache.lucene.analysis.icu.segmentation.DefaultICUTokenizerConfig.clinit(DefaultICUTokenizerConfig.java:73)
   Somebody can help me?
 Page ref.: http://lucene.apache.org/core/4_2_0/analyzers-icu/index.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4671) CSV Should Support pseudo fields

2013-04-04 Thread Ryan McKinley (JIRA)


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

Ryan McKinley updated SOLR-4671:


Issue Type: Improvement  (was: Bug)
   Summary: CSV Should Support pseudo fields  (was: CSV Formating)

CSV formatting does not support any of the pseudo-field stuff.

If you put in fl=[docid],id it will give you an NPE!

 CSV Should Support pseudo fields
 

 Key: SOLR-4671
 URL: https://issues.apache.org/jira/browse/SOLR-4671
 Project: Solr
  Issue Type: Improvement
Affects Versions: 4.2
 Environment: Linux Server with Tomcat
Reporter: nihed mbarek
 Attachments: result.csv


 We just discover that we can't have alias for CSV Formating 
 http://127.0.0.1:8983/solr/collection1/select?q=*%3A*fl=score%2C+idprod%3Aidwt=csvindent=true
 using this schema 
 https://issues.apache.org/jira/secure/attachment/12576952/schema.xml
 for the standard core collection 
 = result as attachment 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-4907) Tokenizer

2013-04-04 Thread Otis Gospodnetic (JIRA)


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

Otis Gospodnetic resolved LUCENE-4907.
--

Resolution: Invalid

Please ask on the mailing list.

 Tokenizer
 -

 Key: LUCENE-4907
 URL: https://issues.apache.org/jira/browse/LUCENE-4907
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
 Environment: WINDOWS 7, NETBEANS 7.2.1
Reporter: luciano aparecido dos santos

 Hi,
 I'm trying to remove the accents in the search, find words removing 
 special characters such as accents (ANDRÉ equals ANDRE).
 I found the class ICUTokenizer but got the Exception in thread main 
 java.lang.NoSuchMethodError: 
 com.ibm.icu.text.UnicodeSet.freeze()Lcom/ibm/icu/text/UnicodeSet;
   at 
 org.apache.lucene.analysis.icu.segmentation.LaoBreakIterator.clinit(LaoBreakIterator.java:73)
   at 
 org.apache.lucene.analysis.icu.segmentation.DefaultICUTokenizerConfig.clinit(DefaultICUTokenizerConfig.java:73)
   Somebody can help me?
 Page ref.: http://lucene.apache.org/core/4_2_0/analyzers-icu/index.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4858) Early termination with SortingMergePolicy

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

Shai Erera commented on LUCENE-4858:

bq. Now that SORTER_ID_PROP is added to the diagnostics, maybe that
SORTED_DIAGNOSTICS_PROP is redundant?

Good point.

bq. Nothing prevent you from wrapping eg. a TotalHitCountCollector inside it

Well, I think that's the point where we're trying to protect the user too much.
I suggest that we commit what we have, maybe clarify the javadocs to explain
better what early termination means, and fix/make it more robust when users
actually trip on something.

bq. I'll work on improving documentation as well.

Thanks. Would you mind to get rid of SORTED prop in that patch too?

Early termination with SortingMergePolicy
-

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

Attachments: LUCENE-4858.patch, LUCENE-4858.patch, LUCENE-4858.patch

Spin-off of LUCENE-4752, see
https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13606565page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13606565
and
https://issues.apache.org/jira/browse/LUCENE-4752?focusedCommentId=13607282page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13607282
When an index is sorted per-segment, queries that sort according to the index
sort order could be early terminated.

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

[jira] [Commented] (LUCENE-4904) Sorter API: Make NumericDocValuesSorter able to sort in reverse order


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

Shai Erera commented on LUCENE-4904:


Maybe instead of fixing NumericDVSorter, we can have a ReverseSortSorter (must 
have a better name!) which wraps any Sorter and reverses the DocMap?

 Sorter API: Make NumericDocValuesSorter able to sort in reverse order
 -

 Key: LUCENE-4904
 URL: https://issues.apache.org/jira/browse/LUCENE-4904
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Trivial
  Labels: newdev
 Fix For: 4.3


 Today it is only able to sort in ascending order.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4874) Don't override non abstract methods that have an impl through other abstract methods in FilterAtomicReader and related classes


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

Adrien Grand updated LUCENE-4874:
-

Summary: Don't override non abstract methods that have an impl through 
other abstract methods in FilterAtomicReader and related classes  (was: Don't 
override non abstract methods in FilterAtomicReader and related classes)

 Don't override non abstract methods that have an impl through other abstract 
 methods in FilterAtomicReader and related classes
 --

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


 Terms.intersect is an optional method. The fact that it is overridden in 
 FilterTerms forces any non-trivial class that extends FilterTerms to override 
 intersect in order this method to have a correct behavior. If FilterTerms did 
 not override this method and used the default impl, we would not have this 
 problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-4648) Create a PreAnalyzedUpdateProcessor

2013-04-04 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  commented on SOLR-4648:
-

bq. minor: in the URP, for (Object o : src.getValues()) { can be for (Object 
o : src) { since it implements Iterable

I'll fix this before committing. Thanks again for the review.

bq. PreAnalyzedUpdateProcessorFactory.createFieldType() ..

+1 to create a separate issue.

 Create a PreAnalyzedUpdateProcessor
 ---

 Key: SOLR-4648
 URL: https://issues.apache.org/jira/browse/SOLR-4648
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.3, 5.0
Reporter: Andrzej Bialecki 
Assignee: Andrzej Bialecki 
 Fix For: 4.3, 5.0

 Attachments: SOLR-4648.patch, SOLR-4648.patch, SOLR-4648.patch, 
 SOLR-4648.patch


 Spin-off from the discussion in SOLR-4619.
 Instead of using a PreAnalyzedField type we can use an UpdateRequestProcessor 
 that converts any input field values to StorableField-s, using the 
 PreAnalyzedParser-s, and then directly passes StorableField-s to 
 DocumentBuilder for indexing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4874) Don't override non abstract methods that have an impl through other abstract methods in FilterAtomicReader and related classes


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

Adrien Grand updated LUCENE-4874:
-

Attachment: LUCENE-4874.patch

Updated patch. I added back attributes modified the test (+ comments) and added 
a changelog entry.

 Don't override non abstract methods that have an impl through other abstract 
 methods in FilterAtomicReader and related classes
 --

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


 Terms.intersect is an optional method. The fact that it is overridden in 
 FilterTerms forces any non-trivial class that extends FilterTerms to override 
 intersect in order this method to have a correct behavior. If FilterTerms did 
 not override this method and used the default impl, we would not have this 
 problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Resolved] (LUCENE-4905) make maxPassages per-field in postingshighlighter


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

Robert Muir resolved LUCENE-4905.
-

   Resolution: Fixed
Fix Version/s: 4.3
   5.0

 make maxPassages per-field in postingshighlighter
 -

 Key: LUCENE-4905
 URL: https://issues.apache.org/jira/browse/LUCENE-4905
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Robert Muir
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4905.patch


 in case you e.g. want smaller summarizes for a bunch of little fields and 
 then a bit bigger one for the body field and so on.
 We can do this by only changing the 'expert' methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4874) Don't override non abstract methods that have an impl through other abstract methods in FilterAtomicReader and related classes


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

Robert Muir commented on LUCENE-4874:
-

+1, thanks for working on these API issues!

 Don't override non abstract methods that have an impl through other abstract 
 methods in FilterAtomicReader and related classes
 --

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


 Terms.intersect is an optional method. The fact that it is overridden in 
 FilterTerms forces any non-trivial class that extends FilterTerms to override 
 intersect in order this method to have a correct behavior. If FilterTerms did 
 not override this method and used the default impl, we would not have this 
 problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-4904) Sorter API: Make NumericDocValuesSorter able to sort in reverse order


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

Adrien Grand commented on LUCENE-4904:
--

That's another option. I have no strong feeling towards any of them.

 Sorter API: Make NumericDocValuesSorter able to sort in reverse order
 -

 Key: LUCENE-4904
 URL: https://issues.apache.org/jira/browse/LUCENE-4904
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Trivial
  Labels: newdev
 Fix For: 4.3


 Today it is only able to sort in ascending order.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Re: Welcome Shalin Shekhar Mangar to the PMC

2013-04-04 Thread Erick Erickson

Welcome!

On Thu, Apr 4, 2013 at 1:33 PM, Adrien Grand jpou...@gmail.com wrote:
 Welcome Shalin!

 --
 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

Re: Welcome Shalin Shekhar Mangar to the PMC

2013-04-04 Thread Robert Muir

Welcome!

On Thu, Apr 4, 2013 at 2:24 PM, Steve Rowe sar...@gmail.com wrote:

 I'm pleased to announce that Shalin Shekhar Mangar has accepted the PMC's
 invitation to join.

 Welcome Shalin!

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

[jira] [Commented] (LUCENE-4874) Don't override non abstract methods that have an impl through other abstract methods in FilterAtomicReader and related classes

2013-04-04 Thread Commit Tag Bot (JIRA)


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

Commit Tag Bot commented on LUCENE-4874:


[trunk commit] jpountz
http://svn.apache.org/viewvc?view=revisionrevision=1464710

LUCENE-4874: Don't override non abstract methods that have an impl through
other abstract methods in FilterAtomicReader and related classes.

 Don't override non abstract methods that have an impl through other abstract 
 methods in FilterAtomicReader and related classes
 --

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


 Terms.intersect is an optional method. The fact that it is overridden in 
 FilterTerms forces any non-trivial class that extends FilterTerms to override 
 intersect in order this method to have a correct behavior. If FilterTerms did 
 not override this method and used the default impl, we would not have this 
 problem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (LUCENE-3538) fix java7 warnings in the source code

2013-04-04 Thread Furkan KAMACI (JIRA)


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

Furkan KAMACI commented on LUCENE-3538:
---

Uwe: Ok, I get the warnings too. I will fix it and upload patch for it.

 fix java7 warnings in the source code
 -

 Key: LUCENE-3538
 URL: https://issues.apache.org/jira/browse/LUCENE-3538
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Robert Muir
  Labels: newdev

 Now that oracle has fixed java7 bugs, I imagine some users will want to use 
 it.
 Currently if you compile lucene's code with java7 you get a ton of 
 warnings... lets clean this up

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (LUCENE-4899) FastVectorHighlihgter fails with SIOOB if single phrase or term is fragCharSize

2013-04-04 Thread Simon Willnauer (JIRA)


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

Simon Willnauer updated LUCENE-4899:


Attachment: LUCENE-4899.patch

thanks koji for looking at it. Yet, I think we shouldn't fix this in the way I 
proposed it in the previous patch. I rather think if we have a single phrase 
that is greater than the fragCharSize we should just not highlight that passage 
at all. This is more conservative here and I think the correct thing to do 
otherwise we can easily end up with phrases way bigger than the fragment char 
size. I tried to simplify this BaseFragListBuilder a bit and make this entire 
behaviour pluggable so folks can decide if they want to risk the size of the 
fragments to explode? 

koji can you take a look at this again?

 FastVectorHighlihgter fails with SIOOB if single phrase or term is  
 fragCharSize
 -

 Key: LUCENE-4899
 URL: https://issues.apache.org/jira/browse/LUCENE-4899
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.0, 4.1, 4.2, 3.6.2, 4.2.1
Reporter: Simon Willnauer
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4899.patch, LUCENE-4899.patch


 This has been reported on several occasions like SOLR-4660 /  SOLR-4137 or on 
 the ES mailing list 
 https://groups.google.com/d/msg/elasticsearch/IdyMSPK5gao/nKZq8_NYWmgJ
 The reason is that the current code expects the fragCharSize  matchLength 
 which is not necessarily true if you use phrases or if you have very long 
 terms like URLs or so. I have a test that reproduces the issue and a fix as 
 far as I can tell (me doesn't have much experience with the highlighter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4672) requests for cores which had known startup init failures should result in 500 not 404