date:20130407

David Smiley created LUCENE-4914:


 Summary: Spatial PrefixTree Node/Cell reset() doesn't reset 'leaf' 
flag
 Key: LUCENE-4914
 URL: https://issues.apache.org/jira/browse/LUCENE-4914
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 4.2
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 5.0, 4.3


The SpatialPrefixTree Cell (formerly known as Node) was refactored in 
LUCENE-4794 which made it into Lucene 4.2.  It introduced an explicit internal 
leaf flag that was formerly computed by examining shapeRel.  However, reset() 
doesn't reset this new flag.

The bug affects SpatialRecursivePrefixTreeStrategy on non-point indexed shapes.

--
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-4914) Spatial PrefixTree Node/Cell reset() doesn't reset 'leaf' flag


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

David Smiley updated LUCENE-4914:
-

Attachment: LUCENE-4914__Spatial_Cell_reset()_forgot_the__leaf__flag_.patch

I'll commit to both branches momentarily.

 Spatial PrefixTree Node/Cell reset() doesn't reset 'leaf' flag
 --

 Key: LUCENE-4914
 URL: https://issues.apache.org/jira/browse/LUCENE-4914
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 4.2
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 5.0, 4.3

 Attachments: 
 LUCENE-4914__Spatial_Cell_reset()_forgot_the__leaf__flag_.patch


 The SpatialPrefixTree Cell (formerly known as Node) was refactored in 
 LUCENE-4794 which made it into Lucene 4.2.  It introduced an explicit 
 internal leaf flag that was formerly computed by examining shapeRel.  
 However, reset() doesn't reset this new flag.
 The bug affects SpatialRecursivePrefixTreeStrategy on non-point indexed 
 shapes.

--
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-4914) Spatial PrefixTree Node/Cell reset() doesn't reset 'leaf' flag


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

David Smiley resolved LUCENE-4914.
--

   Resolution: Fixed
Lucene Fields: New,Patch Available  (was: New)

 Spatial PrefixTree Node/Cell reset() doesn't reset 'leaf' flag
 --

 Key: LUCENE-4914
 URL: https://issues.apache.org/jira/browse/LUCENE-4914
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 4.2
Reporter: David Smiley
Assignee: David Smiley
 Fix For: 5.0, 4.3

 Attachments: 
 LUCENE-4914__Spatial_Cell_reset()_forgot_the__leaf__flag_.patch


 The SpatialPrefixTree Cell (formerly known as Node) was refactored in 
 LUCENE-4794 which made it into Lucene 4.2.  It introduced an explicit 
 internal leaf flag that was formerly computed by examining shapeRel.  
 However, reset() doesn't reset this new flag.
 The bug affects SpatialRecursivePrefixTreeStrategy on non-point indexed 
 shapes.

--
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-4913) FacetResultNode.ordinal is always 0 when all facets are requested


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

Michael McCandless commented on LUCENE-4913:


Thanks Shai!

bq. Mike, I think the CHANGES entry though is slightly incorrect - it's not 
related to ALL_PARENTS, but rather to when you ask for all children (or any 
numResults = taxo.size())? 

Sorry, I had just seen it originally with ALL_PARENTS ... I'll fix the CHANGES 
and commit!

 FacetResultNode.ordinal is always 0 when all facets are requested
 -

 Key: LUCENE-4913
 URL: https://issues.apache.org/jira/browse/LUCENE-4913
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/facet
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4913.patch, LUCENE-4913.patch


 Silly bug ... we just fail to set the ordinal in IntFacetResultsHandler.

--
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-4913) FacetResultNode.ordinal is always 0 when all facets are requested


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

Michael McCandless resolved LUCENE-4913.


Resolution: Fixed

 FacetResultNode.ordinal is always 0 when all facets are requested
 -

 Key: LUCENE-4913
 URL: https://issues.apache.org/jira/browse/LUCENE-4913
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/facet
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4913.patch, LUCENE-4913.patch


 Silly bug ... we just fail to set the ordinal in IntFacetResultsHandler.

--
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-4885) each FacetResult should return the facet equivalent of totalHits


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

Michael McCandless commented on LUCENE-4885:


OK I'll move it to FRN instead ... that's a good idea.

 each FacetResult should return the facet equivalent of totalHits
 

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

 Attachments: LUCENE-4885.patch


 This is cheap to compute, since the TopKFRH already must visit all 
 non-zero-count ords under the FacetRequest.categoryPath.
 This can be useful to a front end, eg to know whether to present a More... 
 under that dimension or not, whether to use a suggester like LinkedIn's facet 
 UI, etc.

--
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-4885) each FacetResult should return the facet equivalent of totalHits


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

Michael McCandless updated LUCENE-4885:
---

Attachment: LUCENE-4885.patch

New patch, moving the count to FacetResultNode.

I'm sure it's possible to get this count for the TopKInEach case but I don't 
understand the code well enough so it's -1 for now.

Also ... I'm not sure this count really belongs in the FRN: it seems quite 
wasteful in the common case of single root and lots of children to have this 
unused int on each child node.  Or I guess the issue is that we don't have a 
separate class for the leaf vs for intermediate nodes.  I guess the wasted 
int doesn't usually matter, since you usually don't request too many children, 
and these classes are transient ...

 each FacetResult should return the facet equivalent of totalHits
 

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

 Attachments: LUCENE-4885.patch, LUCENE-4885.patch


 This is cheap to compute, since the TopKFRH already must visit all 
 non-zero-count ords under the FacetRequest.categoryPath.
 This can be useful to a front end, eg to know whether to present a More... 
 under that dimension or not, whether to use a suggester like LinkedIn's facet 
 UI, etc.

--
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-4915) DrillSideways should accept drill down fields that are not faceted

Michael McCandless created LUCENE-4915:
--

 Summary: DrillSideways should accept drill down fields that are 
not faceted
 Key: LUCENE-4915
 URL: https://issues.apache.org/jira/browse/LUCENE-4915
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless


Today if you drill down on a field but don't do facet counts on it, 
DrillSideways throws an exception.

The caller can work around this: it must take all such drill-downs and manually 
move them into the base query as BQ MUST clauses.  But I think DrillSideways 
should do this.

I hit this when trying to add a See all... link on a facet dim that has way 
too many labels to normally show: in this case I run a new search, but I facet 
only on this one dimension, when there could be drill-downs on other dimensions.

--
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] [Assigned] (LUCENE-4915) DrillSideways should accept drill down fields that are not faceted


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

Michael McCandless reassigned LUCENE-4915:
--

Assignee: Michael McCandless

 DrillSideways should accept drill down fields that are not faceted
 --

 Key: LUCENE-4915
 URL: https://issues.apache.org/jira/browse/LUCENE-4915
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless

 Today if you drill down on a field but don't do facet counts on it, 
 DrillSideways throws an exception.
 The caller can work around this: it must take all such drill-downs and 
 manually move them into the base query as BQ MUST clauses.  But I think 
 DrillSideways should do this.
 I hit this when trying to add a See all... link on a facet dim that has way 
 too many labels to normally show: in this case I run a new search, but I 
 facet only on this one dimension, when there could be drill-downs on other 
 dimensions.

--
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-4915) DrillSideways should accept drill down fields that are not faceted


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

Michael McCandless updated LUCENE-4915:
---

Fix Version/s: 4.3
   5.0

 DrillSideways should accept drill down fields that are not faceted
 --

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


 Today if you drill down on a field but don't do facet counts on it, 
 DrillSideways throws an exception.
 The caller can work around this: it must take all such drill-downs and 
 manually move them into the base query as BQ MUST clauses.  But I think 
 DrillSideways should do this.
 I hit this when trying to add a See all... link on a facet dim that has way 
 too many labels to normally show: in this case I run a new search, but I 
 facet only on this one dimension, when there could be drill-downs on other 
 dimensions.

--
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-3069) Lucene should have an entirely memory resident term dictionary

2013-04-07 Thread Han Jiang (JIRA)


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

Han Jiang commented on LUCENE-3069:
---

This project is quite interesting!

Since we already have an entirely memory resident PF, the target of this 
project seems to be as below:
1. implement a simplified version of BlockTreeTerms*;
2. change the API of current PostingsBastFormat, so that some non-block-based 
term dic will be possible to plug in it.(ideally, MemoryPF should work with 
this)

 Lucene should have an entirely memory resident term dictionary
 --

 Key: LUCENE-3069
 URL: https://issues.apache.org/jira/browse/LUCENE-3069
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index, core/search
Affects Versions: 4.0-ALPHA
Reporter: Simon Willnauer
Assignee: Simon Willnauer
  Labels: gsoc2013
 Fix For: 4.3


 FST based TermDictionary has been a great improvement yet it still uses a 
 delta codec file for scanning to terms. Some environments have enough memory 
 available to keep the entire FST based term dict in memory. We should add a 
 TermDictionary implementation that encodes all needed information for each 
 term into the FST (custom fst.Output) and builds a FST from the entire term 
 not just the delta.

--
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-4885) each FacetResult should return the facet equivalent of totalHits

2013-04-07 Thread Shai Erera (JIRA)

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

Shai Erera commented on LUCENE-4885:

I hear you. That's why I first, too, thought it should be on FacetResult, and
that we can just use numValidDescendants. I'm torn here too, not sure what to
do about TopKInEachNode. I guess that we could resolve this by separating FRN
and TreeFRN, while FRN recording ordinal, value and label and TreeFRN recording
subResults and uniqueChildrenCount? The problem is how to iterate on the
results...

Hmm, maybe the cut needs to be higher up at FacetResult level, with FacetResult
(flat) and HierarchicalFacetResult. FacetResult will give you an IteratorFRN
and if it's Hierarchical or TreeFacetResult), you get in practice an
IteratorTreeFRN ... also, FR will record uniqueChildrenCount. For TreeFR this
can mean the total unique count, or just at the root level...

Today, for the common case, we spend a List pointer at each FRN, which is null.
Perhaps, as you say, it's usually a non issue since you ask for a low K ...

One other solution would be to hide the uniqueChildrenCount and subResults
behind methods, so that FRN returns -1 and null, while TreeFRN implements them
accordingly?

In general, I feel that FacetResult and FRN are too verbose. I think that the
root node's statistics could be available from the FacetResult level, and that
it could give you an iterator directly, rather than giving you a node which you
always *must* call root.subResults... but it's for a separate issue.

Regarding TopKInEachNode, I wonder if we should eliminate that completely from
FacetRequest, and create an appropriate FacetResultHander which you configure
with the levels that you want, including (potentially, in the future) different
K values for different levels?

each FacetResult should return the facet equivalent of totalHits

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

Attachments: LUCENE-4885.patch, LUCENE-4885.patch

This is cheap to compute, since the TopKFRH already must visit all
non-zero-count ords under the FacetRequest.categoryPath.
This can be useful to a front end, eg to know whether to present a More...
under that dimension or not, whether to use a suggester like LinkedIn's facet
UI, etc.

--
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-2962) Skip data should be inlined into the postings lists

2013-04-07 Thread Han Jiang (JIRA)

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

Han Jiang commented on LUCENE-2962:
---

Hi, here is my understanding about this issue (after discussion with Mike),
hope this can be a right summary:

Extra penalty on current impl:
1. Skip data for both doc(.doc) and positions(.pos) are gathered inside the
same blob(in .doc). For non-proximity queries, it takes unnecessary decode time.
2. In MultiLevelSkipReader, each level of skip takes an inputstream, while they
are jumping inside the same file, along with the docIn loading docid/freqs. If
skip data are just interleaved, the jumping behavior might be less frequent (as
is said private) for IO cache.

And, to inline skip data into postings list, there will be something to dig
more:
1. Buffering, since we can hardly predict which FP to skip to, we might have to
buffer the following postings data in memory to calculate FP offset.
2. The file structure of MultiLevelSkipWriter(even with skip blob splitted) is
still a little bit different from the paper in Mike's comment, which can be
illustrated by Figure.4 vs Figure 7 in that paper.

Skip data should be inlined into the postings lists
---

Key: LUCENE-2962
URL: https://issues.apache.org/jira/browse/LUCENE-2962
Project: Lucene - Core
Issue Type: Improvement
Components: core/index
Reporter: Michael McCandless
Labels: gsoc2013

Today, we store all skip data as a separate blob at the end of a given term's
postings (if that term occurs in enough docs to warrant skip data).
But this adds overhead during decoding -- we have to seek to a different
place for the initial load, we have to init separate readers, we have to seek
again while using the lower levels of the skip data, etc. Also, we have to
fully decode all skip information even if we are not going to use it (eg if I
only want docIDs, I still must decode position offset and lastPayloadLength).
If instead we interleaved skip data into the postings file, we could keep it
local, and private to each file that needs skipping. This should make it
least costly to init and then use the skip data, which'd be a good perf gain
for eg PhraseQuery, AndQuery.

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

[jira] [Updated] (LUCENE-4915) DrillSideways should accept drill down fields that are not faceted

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

Michael McCandless updated LUCENE-4915:
---

Attachment: LUCENE-4915.patch

Patch ... I think it's ready.

I also relaxed another anal-ness of DrillSideways, that it would fail if you
didn't have any drill-downs. In this case now I just fallback to an ordinary
search...

DrillSideways should accept drill down fields that are not faceted
--

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

Attachments: LUCENE-4915.patch

Today if you drill down on a field but don't do facet counts on it,
DrillSideways throws an exception.
The caller can work around this: it must take all such drill-downs and
manually move them into the base query as BQ MUST clauses. But I think
DrillSideways should do this.
I hit this when trying to add a See all... link on a facet dim that has way
too many labels to normally show: in this case I run a new search, but I
facet only on this one dimension, when there could be drill-downs on other
dimensions.

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

[jira] [Commented] (LUCENE-4885) each FacetResult should return the facet equivalent of totalHits

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

Michael McCandless commented on LUCENE-4885:

bq. In general, I feel that FacetResult and FRN are too verbose. I think that
the root node's statistics could be available from the FacetResult level, and
that it could give you an iterator directly, rather than giving you a node
which you always must call root.subResults... but it's for a separate issue.

I agree!

Also, sometimes you do need to pull a large number of facet results (the See
all... case) ... and I wonder if we should just do parallel arrays, ie
String[] labels and int[]/double[] values, for flat results, or only expose an
iterator.

bq. Regarding TopKInEachNode, I wonder if we should eliminate that completely
from FacetRequest, and create an appropriate FacetResultHander which you
configure with the levels that you want, including (potentially, in the future)
different K values for different levels?

each FacetResult should return the facet equivalent of totalHits

Attachments: LUCENE-4885.patch, LUCENE-4885.patch

-
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-07 Thread Anshum Gupta (JIRA)


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

Anshum Gupta commented on SOLR-3755:


All of the above mentioned issues (and more) are now fixed.

 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

[jira] [Commented] (LUCENE-4910) JapaneseTokenizer NullPointerException

2013-04-07 Thread Shuji Umino (JIRA)


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

Shuji Umino commented on LUCENE-4910:
-

Its not worked same code written by Lucene 4.0
Why call 'reset', please tell this means.

 JapaneseTokenizer NullPointerException
 --

 Key: LUCENE-4910
 URL: https://issues.apache.org/jira/browse/LUCENE-4910
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
Reporter: Shuji Umino

 I use lucene 4.2.1 upgrade from 4.0.
 RollingCharBuffer required Reader, 
 buffer.init(null) called in JapaneseTokenizer custructor.
  Test code
 --
 public static void main(String[] args) throws Exception {
   String text = test abc;
   JapaneseTokenizer tokenizer = new JapaneseTokenizer(
   new StringReader(text), null, false, Mode.NORMAL);
   //tokenizer.reset();
   
   while (tokenizer.incrementToken()) {
   CharTermAttribute termAtt = 
 tokenizer.getAttribute(CharTermAttribute.class);
   System.out.println(termAtt);
   }
 }
  Exception
 --
 Exception in thread main java.lang.NullPointerException
   at 
 org.apache.lucene.analysis.util.RollingCharBuffer.get(RollingCharBuffer.java:86)
   at 
 org.apache.lucene.analysis.ja.JapaneseTokenizer.parse(JapaneseTokenizer.java:602)
   at 
 org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:452)
 --

--
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] (LUCENE-4910) JapaneseTokenizer NullPointerException

2013-04-07 Thread Shuji Umino (JIRA)


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

Shuji Umino edited comment on LUCENE-4910 at 4/7/13 8:53 PM:
-

Its not worked same code written by Lucene 4.0
Why call 'reset' on first time, please tell this means.

  was (Author: umishu):
Its not worked same code written by Lucene 4.0
Why call 'reset', please tell this means.
  
 JapaneseTokenizer NullPointerException
 --

 Key: LUCENE-4910
 URL: https://issues.apache.org/jira/browse/LUCENE-4910
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
Reporter: Shuji Umino

 I use lucene 4.2.1 upgrade from 4.0.
 RollingCharBuffer required Reader, 
 buffer.init(null) called in JapaneseTokenizer custructor.
  Test code
 --
 public static void main(String[] args) throws Exception {
   String text = test abc;
   JapaneseTokenizer tokenizer = new JapaneseTokenizer(
   new StringReader(text), null, false, Mode.NORMAL);
   //tokenizer.reset();
   
   while (tokenizer.incrementToken()) {
   CharTermAttribute termAtt = 
 tokenizer.getAttribute(CharTermAttribute.class);
   System.out.println(termAtt);
   }
 }
  Exception
 --
 Exception in thread main java.lang.NullPointerException
   at 
 org.apache.lucene.analysis.util.RollingCharBuffer.get(RollingCharBuffer.java:86)
   at 
 org.apache.lucene.analysis.ja.JapaneseTokenizer.parse(JapaneseTokenizer.java:602)
   at 
 org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:452)
 --

--
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-4910) JapaneseTokenizer NullPointerException

2013-04-07 Thread Uwe Schindler (JIRA)


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

Uwe Schindler commented on LUCENE-4910:
---

Read the Javadocs of the TokenStream class, it is documented like that. No more 
discussion needed.

 JapaneseTokenizer NullPointerException
 --

 Key: LUCENE-4910
 URL: https://issues.apache.org/jira/browse/LUCENE-4910
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
Reporter: Shuji Umino

 I use lucene 4.2.1 upgrade from 4.0.
 RollingCharBuffer required Reader, 
 buffer.init(null) called in JapaneseTokenizer custructor.
  Test code
 --
 public static void main(String[] args) throws Exception {
   String text = test abc;
   JapaneseTokenizer tokenizer = new JapaneseTokenizer(
   new StringReader(text), null, false, Mode.NORMAL);
   //tokenizer.reset();
   
   while (tokenizer.incrementToken()) {
   CharTermAttribute termAtt = 
 tokenizer.getAttribute(CharTermAttribute.class);
   System.out.println(termAtt);
   }
 }
  Exception
 --
 Exception in thread main java.lang.NullPointerException
   at 
 org.apache.lucene.analysis.util.RollingCharBuffer.get(RollingCharBuffer.java:86)
   at 
 org.apache.lucene.analysis.ja.JapaneseTokenizer.parse(JapaneseTokenizer.java:602)
   at 
 org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:452)
 --

--
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-4910) JapaneseTokenizer NullPointerException

2013-04-07 Thread Simon Willnauer (JIRA)


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

Simon Willnauer commented on LUCENE-4910:
-

Shuji, what uwe says is that this might have worked in Lucene 4.0 but given the 
contract this API has the behaviour undefined unless you call 
TokenStream#reset() before you consume it. The NullPointerException is a result 
of this undefined behaviour due to the missing reset call and should be fixed 
by simply calling reset(). 

happy searching.

simon

 JapaneseTokenizer NullPointerException
 --

 Key: LUCENE-4910
 URL: https://issues.apache.org/jira/browse/LUCENE-4910
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/analysis
Affects Versions: 4.2
Reporter: Shuji Umino

 I use lucene 4.2.1 upgrade from 4.0.
 RollingCharBuffer required Reader, 
 buffer.init(null) called in JapaneseTokenizer custructor.
  Test code
 --
 public static void main(String[] args) throws Exception {
   String text = test abc;
   JapaneseTokenizer tokenizer = new JapaneseTokenizer(
   new StringReader(text), null, false, Mode.NORMAL);
   //tokenizer.reset();
   
   while (tokenizer.incrementToken()) {
   CharTermAttribute termAtt = 
 tokenizer.getAttribute(CharTermAttribute.class);
   System.out.println(termAtt);
   }
 }
  Exception
 --
 Exception in thread main java.lang.NullPointerException
   at 
 org.apache.lucene.analysis.util.RollingCharBuffer.get(RollingCharBuffer.java:86)
   at 
 org.apache.lucene.analysis.ja.JapaneseTokenizer.parse(JapaneseTokenizer.java:602)
   at 
 org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:452)
 --

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

Token Stream with Offsets (Token Sources class)

2013-04-07 Thread vempap

Hi,

  I've the following snippet code where I'm trying to extract weighted span
terms from the query (I do have term vectors enabled on the fields):

File path = new File(
path-to-index-dir);
FSDirectory directory = FSDirectory.open(path);
IndexReader indexReader = DirectoryReader.open(directory);

MapString, WeightedSpanTerm allWeightedSpanTerms = new 
HashMapString,
WeightedSpanTerm();

WeightedSpanTermExtractor extractor = null;
extractor = new WeightedSpanTermExtractor();
TokenStream tokenStream = null;
tokenStream = 
TokenSources.getTokenStreamWithOffsets(indexReader, 0,
name);
allWeightedSpanTerms.putAll(extractor.getWeightedSpanTerms(q,
tokenStream));

In the end, if I look at the map allWeightedSpanTerms - I don't have any
weighted span terms  when I tried to debug the code I found that when it is
trying to build the TermContext the statement fields.terms(field); is
returning null which I don't understand.

My query is : Running Apple (a phrase query)
my doc contents are :
name : Running Apple 60 GB iPod with Video Playback Black - Apple

Please let me know on what I'm doing anything wrong.

Thanks,
Phani.




--
View this message in context: 
http://lucene.472066.n3.nabble.com/Token-Stream-with-Offsets-Token-Sources-class-tp4054385.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

[jira] [Commented] (SOLR-4655) The Overseer should assign node names by default.

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

Mark Miller commented on SOLR-4655:
---

For back compat, I have added a new config option at the core container level
called genericNodesNames - it will default to true in the next release, but
it's absence will be equal to false.

The Overseer should assign node names by default.
-

Key: SOLR-4655
URL: https://issues.apache.org/jira/browse/SOLR-4655
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Fix For: 4.3, 5.0

Currently we make a unique node name by using the host address as part of the
name. This means that if you want a node with a new address to take over, the
node name is misleading. It's best if you set custom names for each node
before starting your cluster. This is cumbersome though, and cannot currently
be done with the collections API. Instead, the overseer could assign a more
generic name such as nodeN by default. Then you can easily swap in another
node with no pre planning and no confusion in the name.

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

[jira] [Comment Edited] (SOLR-4655) The Overseer should assign node names by default.

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

Mark Miller edited comment on SOLR-4655 at 4/8/13 1:01 AM:
---

For back compat, I have added a new config option at the core container level
called genericNodeNames - it will default to true in the next release, but it's
absence will be equal to false.

was (Author: markrmil...@gmail.com):
For back compat, I have added a new config option at the core container
level called genericNodesNames - it will default to true in the next release,
but it's absence will be equal to false.

The Overseer should assign node names by default.
-

Key: SOLR-4655
URL: https://issues.apache.org/jira/browse/SOLR-4655
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Fix For: 4.3, 5.0

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

[jira] [Updated] (SOLR-4655) The Overseer should assign node names by default.


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

Mark Miller updated SOLR-4655:
--

Attachment: SOLR-4655.patch

 The Overseer should assign node names by default.
 -

 Key: SOLR-4655
 URL: https://issues.apache.org/jira/browse/SOLR-4655
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.3, 5.0

 Attachments: SOLR-4655.patch


 Currently we make a unique node name by using the host address as part of the 
 name. This means that if you want a node with a new address to take over, the 
 node name is misleading. It's best if you set custom names for each node 
 before starting your cluster. This is cumbersome though, and cannot currently 
 be done with the collections API. Instead, the overseer could assign a more 
 generic name such as nodeN by default. Then you can easily swap in another 
 node with no pre planning and no confusion in the name.

--
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-4667) Our logging configuration files should set ZooKeeper logging to WARN

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


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

Commit Tag Bot commented on SOLR-4667:
--

[branch_4x commit] markrmiller
http://svn.apache.org/viewvc?view=revisionrevision=1465532

SOLR-4667: Our logging configuration files should set ZooKeeper logging to WARN

 Our logging configuration files should set ZooKeeper logging to WARN
 

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


 This helps a lot with cleaning up the logs.

--
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-4667) Our logging configuration files should set ZooKeeper logging to WARN


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

Mark Miller commented on SOLR-4667:
---

Committed to trunk as well, commit bot was just off momentarily (not setup 
permanently quite yet).

 Our logging configuration files should set ZooKeeper logging to WARN
 

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


 This helps a lot with cleaning up the logs.

--
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-4667) Our logging configuration files should set ZooKeeper logging to WARN


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

Mark Miller resolved SOLR-4667.
---

Resolution: Fixed

 Our logging configuration files should set ZooKeeper logging to WARN
 

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


 This helps a lot with cleaning up the logs.

--
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-4685) JSON response write modification to support RAW JSON

Bill Bell created SOLR-4685:
---

 Summary: JSON response write modification to support RAW JSON
 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Bug
Reporter: Bill Bell


If the field ends with _json allow the field to return raw JSON.

For example the field,

office_json -- string

I put in there ral JSON already escaped. I want it to come with no double 
quotes and not escaped.


--
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-4685) JSON response write modification to support RAW JSON


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

Bill Bell updated SOLR-4685:


Attachment: SOLR-4685.patch

Here is a simple patch. 

 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Bug
Reporter: Bill Bell
 Attachments: SOLR-4685.patch


 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I put in there ral JSON already escaped. I want it to come with no double 
 quotes and not escaped.

--
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-4685) JSON response write modification to support RAW JSON


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

Bill Bell updated SOLR-4685:


Description: 
If the field ends with _json allow the field to return raw JSON.

For example the field,

office_json -- string

I already put into the field raw JSON already escaped. I want it to come with 
no double quotes and not escaped.


  was:
If the field ends with _json allow the field to return raw JSON.

For example the field,

office_json -- string

I put in there ral JSON already escaped. I want it to come with no double 
quotes and not escaped.



 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Bug
Reporter: Bill Bell
 Attachments: SOLR-4685.patch


 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

--
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-4685) JSON response write modification to support RAW JSON


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

Bill Bell updated SOLR-4685:


Attachment: (was: SOLR-4685.patch)

 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Bug
Reporter: Bill Bell

 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

--
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-4685) JSON response write modification to support RAW JSON


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

Bill Bell updated SOLR-4685:


Issue Type: Improvement  (was: Bug)

 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Improvement
Reporter: Bill Bell

 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

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

how to delete a configset in zookeeper?

2013-04-07 Thread wtang

I used solr's zkcli.sh to upconfig and linkconfig a solr config into
zookeeper.
Question is: how can I delete that configset?
Thanks in advance.



--
View this message in context: 
http://lucene.472066.n3.nabble.com/how-to-delete-a-configset-in-zookeeper-tp4054414.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

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

[jira] [Commented] (SOLR-4685) JSON response write modification to support RAW JSON


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

Bill Bell commented on SOLR-4685:
-

OK. I have a solution for SOLR 4.2.1. I added a new field json.fsuffix (field 
suffix). 

{{{
http://localhost:8983/solr/collection1/select?q=*%3A*indent=truerows=50wt=jsonjson.fsuffix=_json
}}}

{{{
  field name=office_json{poffL:{poff:{prNm:Canon Counseling 
LLC,prID:DHDHD,offL:{off:{addCd:R729D,zip:78258,isLab:0,faxL:{faxFull:(210)
 555-1215},oNm:Canon Counseling LLC,isXray:0,oRank:1,ad1:19206 West 
Rd,city:San 
Antonio,pracUrl:/group-directory/texas-tx/san-antonio/canon-counseling-llc,isBStf:0,oGUID:973D43A0-882A-E211-8426-B499BAA4D952,prmryO:1,phL:{phFull:(210)
 
555-1212},addTp:Office,st:TX,oLegacyID:D757D8842019122,isPhrm:0,oID:YX7YLM}},pLegacyID:EDA4E9842019122,prGUID:963D43A0-882A-E211-8426-B499BAA4D952,pProvCnt:1}}}/field
}}}

And you get:

{{{
{
id: 0579B002,
name: Canon PIXMA MP500 All-In-One Photo Printer,
manu: Canon Inc.,
manu_id_s: canon,
cat: [
  electronics,
  multifunction printer,
  printer,
  scanner,
  copier
],
features: [
  Multifunction ink-jet color photo printer,
  Flatbed scanner, optical scan resolution of 1,200 x 2,400 dpi,
  2.5\ color LCD preview screen,
  Duplex Copying,
  Printing speed up to 29ppm black, 19ppm color,
  Hi-Speed USB,
  memory card: CompactFlash, Micro Drive, SmartMedia, Memory Stick, 
Memory Stick Pro, SD Card, and MultiMediaCard
],
weight: 352,
price: 179.99,
price_c: 179.99,USD,
popularity: 6,
inStock: true,
office_json: {
  poffL: {
poff: {
  prNm: Canon Counseling LLC,
  prID: DHDHD,
  offL: {
off: {
  addCd: R729D,
  zip: 78258,
  isLab: 0,
  faxL: {
faxFull: (210) 555-1215
  },
  oNm: Canon Counseling LLC,
  isXray: 0,
  oRank: 1,
  ad1: 19206 West Rd,
  city: San Antonio,
  pracUrl: 
\/group-directory\/texas-tx\/san-antonio\/canon-counseling-llc,
  isBStf: 0,
  oGUID: 973D43A0-882A-E211-8426-B499BAA4D952,
  prmryO: 1,
  phL: {
phFull: (210) 555-1212
  },
  addTp: Office,
  st: TX,
  oLegacyID: D757D8842019122,
  isPhrm: 0,
  oID: YX7YLM
}
  },
  pLegacyID: EDA4E9842019122,
  prGUID: 963D43A0-882A-E211-8426-B499BAA4D952,
  pProvCnt: 1
}
  }
},
store: 45.19214,-93.89941,
_version_: 1.4317228499665e+18
  },
}}}



 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Improvement
Reporter: Bill Bell

 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

--
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-4685) JSON response write modification to support RAW JSON


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

Bill Bell edited comment on SOLR-4685 at 4/8/13 5:10 AM:
-

OK. I have a solution for SOLR 4.2.1. I added a new field json.fsuffix (field 
suffix). 

{noformat}
http://localhost:8983/solr/collection1/select?q=*%3A*indent=truerows=50wt=jsonjson.fsuffix=_json
{noformat}

{noformat}
  field name=office_json{poffL:{poff:{prNm:Canon Counseling 
LLC,prID:DHDHD,offL:{off:{addCd:R729D,zip:78258,isLab:0,faxL:{faxFull:(210)
 555-1215},oNm:Canon Counseling LLC,isXray:0,oRank:1,ad1:19206 West 
Rd,city:San 
Antonio,pracUrl:/group-directory/texas-tx/san-antonio/canon-counseling-llc,isBStf:0,oGUID:973D43A0-882A-E211-8426-B499BAA4D952,prmryO:1,phL:{phFull:(210)
 
555-1212},addTp:Office,st:TX,oLegacyID:D757D8842019122,isPhrm:0,oID:YX7YLM}},pLegacyID:EDA4E9842019122,prGUID:963D43A0-882A-E211-8426-B499BAA4D952,pProvCnt:1}}}/field
{noformat}

And you get:

{noformat}
{
id: 0579B002,
name: Canon PIXMA MP500 All-In-One Photo Printer,
manu: Canon Inc.,
manu_id_s: canon,
cat: [
  electronics,
  multifunction printer,
  printer,
  scanner,
  copier
],
features: [
  Multifunction ink-jet color photo printer,
  Flatbed scanner, optical scan resolution of 1,200 x 2,400 dpi,
  2.5\ color LCD preview screen,
  Duplex Copying,
  Printing speed up to 29ppm black, 19ppm color,
  Hi-Speed USB,
  memory card: CompactFlash, Micro Drive, SmartMedia, Memory Stick, 
Memory Stick Pro, SD Card, and MultiMediaCard
],
weight: 352,
price: 179.99,
price_c: 179.99,USD,
popularity: 6,
inStock: true,
office_json: {
  poffL: {
poff: {
  prNm: Canon Counseling LLC,
  prID: DHDHD,
  offL: {
off: {
  addCd: R729D,
  zip: 78258,
  isLab: 0,
  faxL: {
faxFull: (210) 555-1215
  },
  oNm: Canon Counseling LLC,
  isXray: 0,
  oRank: 1,
  ad1: 19206 West Rd,
  city: San Antonio,
  pracUrl: 
\/group-directory\/texas-tx\/san-antonio\/canon-counseling-llc,
  isBStf: 0,
  oGUID: 973D43A0-882A-E211-8426-B499BAA4D952,
  prmryO: 1,
  phL: {
phFull: (210) 555-1212
  },
  addTp: Office,
  st: TX,
  oLegacyID: D757D8842019122,
  isPhrm: 0,
  oID: YX7YLM
}
  },
  pLegacyID: EDA4E9842019122,
  prGUID: 963D43A0-882A-E211-8426-B499BAA4D952,
  pProvCnt: 1
}
  }
},
store: 45.19214,-93.89941,
_version_: 1.4317228499665e+18
  },
{noformat}


  was (Author: billnbell):
OK. I have a solution for SOLR 4.2.1. I added a new field json.fsuffix 
(field suffix). 

{{{
http://localhost:8983/solr/collection1/select?q=*%3A*indent=truerows=50wt=jsonjson.fsuffix=_json
}}}

{{{
  field name=office_json{poffL:{poff:{prNm:Canon Counseling 
LLC,prID:DHDHD,offL:{off:{addCd:R729D,zip:78258,isLab:0,faxL:{faxFull:(210)
 555-1215},oNm:Canon Counseling LLC,isXray:0,oRank:1,ad1:19206 West 
Rd,city:San 
Antonio,pracUrl:/group-directory/texas-tx/san-antonio/canon-counseling-llc,isBStf:0,oGUID:973D43A0-882A-E211-8426-B499BAA4D952,prmryO:1,phL:{phFull:(210)
 
555-1212},addTp:Office,st:TX,oLegacyID:D757D8842019122,isPhrm:0,oID:YX7YLM}},pLegacyID:EDA4E9842019122,prGUID:963D43A0-882A-E211-8426-B499BAA4D952,pProvCnt:1}}}/field
}}}

And you get:

{{{
{
id: 0579B002,
name: Canon PIXMA MP500 All-In-One Photo Printer,
manu: Canon Inc.,
manu_id_s: canon,
cat: [
  electronics,
  multifunction printer,
  printer,
  scanner,
  copier
],
features: [
  Multifunction ink-jet color photo printer,
  Flatbed scanner, optical scan resolution of 1,200 x 2,400 dpi,
  2.5\ color LCD preview screen,
  Duplex Copying,
  Printing speed up to 29ppm black, 19ppm color,
  Hi-Speed USB,
  memory card: CompactFlash, Micro Drive, SmartMedia, Memory Stick, 
Memory Stick Pro, SD Card, and MultiMediaCard
],
weight: 352,
price: 179.99,
price_c: 179.99,USD,
popularity: 6,
inStock: true,
office_json: {
  poffL: {
poff: {
  prNm: Canon Counseling LLC,
  prID: DHDHD,
  offL: {

[jira] [Resolved] (SOLR-4685) JSON response write modification to support RAW JSON


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

Bill Bell resolved SOLR-4685.
-

Resolution: Fixed

THis is good for SOLR 4.2.1

 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Improvement
Reporter: Bill Bell
 Attachments: SOLR-4685.patch


 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

--
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-4685) JSON response write modification to support RAW JSON


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

Bill Bell updated SOLR-4685:


Attachment: SOLR-4685.patch

 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Improvement
Reporter: Bill Bell
 Attachments: SOLR-4685.patch


 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

--
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-4685) JSON response write modification to support RAW JSON


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

David Smiley commented on SOLR-4685:


Bill, why did you close and mark as fixed?

 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Improvement
Reporter: Bill Bell
 Attachments: SOLR-4685.patch


 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

--
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-4685) JSON response write modification to support RAW JSON


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

Bill Bell commented on SOLR-4685:
-

Whoops!!


 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Improvement
Reporter: Bill Bell
 Attachments: SOLR-4685.patch


 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

--
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] (SOLR-4685) JSON response write modification to support RAW JSON


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

Bill Bell reopened SOLR-4685:
-


 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Improvement
Reporter: Bill Bell
 Attachments: SOLR-4685.patch


 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

--
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-4685) JSON response write modification to support RAW JSON


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

Bill Bell commented on SOLR-4685:
-

You need to add the field as string in schema.xml 

field name=office_json type=string indexed=false stored=true /



 JSON response write modification to support RAW JSON
 

 Key: SOLR-4685
 URL: https://issues.apache.org/jira/browse/SOLR-4685
 Project: Solr
  Issue Type: Improvement
Reporter: Bill Bell
 Attachments: SOLR-4685.patch


 If the field ends with _json allow the field to return raw JSON.
 For example the field,
 office_json -- string
 I already put into the field raw JSON already escaped. I want it to come with 
 no double quotes and not escaped.

--
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-4916) Spatial WithinPrefixTreeFilter can too eagerly find false-positive