[jira] Commented: (SOLR-1568) Implement Spatial Filter

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1568:
--

Hi,

I have taken a look at the latest patch and it seems fine.  Any TODOs and 
problems with the poles can be tackled as separate/sub-issues.  Particularly 
the pole bugs.  I'd prefer to see this committed soon so we can take a look at 
the overall architecture, and see what parts we want to move into a module.

 Implement Spatial Filter
 

 Key: SOLR-1568
 URL: https://issues.apache.org/jira/browse/SOLR-1568
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: CartesianTierQParserPlugin.java, 
 SOLR-1568.Mattmann.031010.patch.txt, SOLR-1568.patch, SOLR-1568.patch, 
 SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch, SOLR-1568.patch


 Given an index with spatial information (either as a geohash, 
 SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be 
 able to pass in a filter query that takes in the field name, lat, lon and 
 distance and produces an appropriate Filter (i.e. one that is aware of the 
 underlying field type for use by Solr. 
 The interface _could_ look like:
 {code}
 fq={!sfilt dist=20}location:49.32,-79.0
 {code}
 or it could be:
 {code}
 fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
 {code}
 or:
 {code}
 fq={!sfilt p=49.32,-79.0 f=location dist=20}
 {code}
 or:
 {code}
 fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
 {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1821) Failing testGetDateFormatEvaluator in TestEvaluatorBag

[Chris Male (JIRA)]

Failing testGetDateFormatEvaluator in TestEvaluatorBag
--

 Key: SOLR-1821
 URL: https://issues.apache.org/jira/browse/SOLR-1821
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 1.5
Reporter: Chris Male


On some TimeZones (such as EDT currently), 
TestEvaluatorBag.testGetDateFormatEvaluator fails with the following error:

{code:xml}
org.junit.ComparisonFailure: 
Expected :2010-03-12 17:15
Actual   :2010-03-12 18:15
at org.junit.Assert.assertEquals(Assert.java:96)
at org.junit.Assert.assertEquals(Assert.java:116)
at 
org.apache.solr.handler.dataimport.TestEvaluatorBag.testGetDateFormatEvaluator(TestEvaluatorBag.java:127)
{code}

This seems due to the reliance on the System ticks in order to create the Date 
to compare against.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1821) Failing testGetDateFormatEvaluator in TestEvaluatorBag

[Chris Male (JIRA)]

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

Chris Male updated SOLR-1821:
-

Attachment: SOLR-1821.patch

Attaching a patch to the test which uses GregorianCalendar instances rather 
than the current System ticks.

 Failing testGetDateFormatEvaluator in TestEvaluatorBag
 --

 Key: SOLR-1821
 URL: https://issues.apache.org/jira/browse/SOLR-1821
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 1.5
Reporter: Chris Male
 Attachments: SOLR-1821.patch


 On some TimeZones (such as EDT currently), 
 TestEvaluatorBag.testGetDateFormatEvaluator fails with the following error:
 {code:xml}
 org.junit.ComparisonFailure: 
 Expected :2010-03-12 17:15
 Actual   :2010-03-12 18:15
   at org.junit.Assert.assertEquals(Assert.java:96)
   at org.junit.Assert.assertEquals(Assert.java:116)
   at 
 org.apache.solr.handler.dataimport.TestEvaluatorBag.testGetDateFormatEvaluator(TestEvaluatorBag.java:127)
 {code}
 This seems due to the reliance on the System ticks in order to create the 
 Date to compare against.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1710) convert worddelimiterfilter to new tokenstream API

[Chris Male (JIRA)]

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

Chris Male updated SOLR-1710:
-

Attachment: SOLR-1710-readable.patch

Attaching a first pass at improving the readability of this code.  

Focused mostly on breaking up #incrementToken, extracting common behavior into 
helper methods, documenting each method, putting fields in a consistent place, 
trimming if else statement blocks etc etc.

I imagine there might be a small performance improvement due to these 
improvements, but they could have all been done by the compiler too.

 convert worddelimiterfilter to new tokenstream API
 --

 Key: SOLR-1710
 URL: https://issues.apache.org/jira/browse/SOLR-1710
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: Robert Muir
 Attachments: SOLR-1710-readable.patch, SOLR-1710.patch, 
 SOLR-1710.patch


 This one was a doozy, attached is a patch to convert it to the new 
 tokenstream API.
 Some of the logic was split into WordDelimiterIterator (exposes a 
 BreakIterator-like api for iterating subwords)
 the filter is much more efficient now, no cloning.
 before applying the patch, copy the existing WordDelimiterFilter to 
 OriginalWordDelimiterFilter
 the patch includes a testcase (TestWordDelimiterBWComp) which generates 
 random strings from various subword combinations.
 For each random string, it compares output against the existing 
 WordDelimiterFilter for all 512 combinations of boolean parameters.
 NOTE: due to bugs found (SOLR-1706), this currently only tests 256 of these 
 combinations. The bugs discovered in SOLR-1706 are fixed here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1710) convert worddelimiterfilter to new tokenstream API

[Chris Male (JIRA)]

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

Chris Male updated SOLR-1710:
-

Attachment: SOLR-1710-readable.patch

Updated patch with method name changes.  doXYZ is now shouldXYZ and writeClear 
is now writeAndClear

 convert worddelimiterfilter to new tokenstream API
 --

 Key: SOLR-1710
 URL: https://issues.apache.org/jira/browse/SOLR-1710
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: Robert Muir
 Attachments: SOLR-1710-readable.patch, SOLR-1710-readable.patch, 
 SOLR-1710.patch, SOLR-1710.patch


 This one was a doozy, attached is a patch to convert it to the new 
 tokenstream API.
 Some of the logic was split into WordDelimiterIterator (exposes a 
 BreakIterator-like api for iterating subwords)
 the filter is much more efficient now, no cloning.
 before applying the patch, copy the existing WordDelimiterFilter to 
 OriginalWordDelimiterFilter
 the patch includes a testcase (TestWordDelimiterBWComp) which generates 
 random strings from various subword combinations.
 For each random string, it compares output against the existing 
 WordDelimiterFilter for all 512 combinations of boolean parameters.
 NOTE: due to bugs found (SOLR-1706), this currently only tests 256 of these 
 combinations. The bugs discovered in SOLR-1706 are fixed here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1657) convert the rest of solr to use the new tokenstream API

[Chris Male (JIRA)]

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

Chris Male updated SOLR-1657:
-

Attachment: SOLR-1657.patch

Attaching a small update to Robert's patch.  Includes some small code 
readability improvements, much along the same lines that I've done for the 
WordDelimiterFilter in SOLR-1710.

 convert the rest of solr to use the new tokenstream API
 ---

 Key: SOLR-1657
 URL: https://issues.apache.org/jira/browse/SOLR-1657
 Project: Solr
  Issue Type: Task
Reporter: Robert Muir
 Attachments: SOLR-1657.patch, SOLR-1657.patch, SOLR-1657.patch


 org.apache.solr.analysis:
 BufferedTokenStream
  - -CommonGramsFilter-
  - -CommonGramsQueryFilter-
  - -RemoveDuplicatesTokenFilter-
 -CapitalizationFilterFactory-
 -HyphenatedWordsFilter-
 -LengthFilter (deprecated, remove)-
 SynonymFilter
 SynonymFilterFactory
 -WordDelimiterFilter-
 org.apache.solr.handler:
 AnalysisRequestHandler
 AnalysisRequestHandlerBase
 org.apache.solr.handler.component:
 QueryElevationComponent
 SpellCheckComponent
 org.apache.solr.highlight:
 DefaultSolrHighlighter
 org.apache.solr.search:
 FieldQParserPlugin
 org.apache.solr.spelling:
 SpellingQueryConverter

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1710) convert worddelimiterfilter to new tokenstream API

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1710:
--

Ah right, sorry missed that description.

 convert worddelimiterfilter to new tokenstream API
 --

 Key: SOLR-1710
 URL: https://issues.apache.org/jira/browse/SOLR-1710
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: Robert Muir
 Attachments: SOLR-1710.patch, SOLR-1710.patch


 This one was a doozy, attached is a patch to convert it to the new 
 tokenstream API.
 Some of the logic was split into WordDelimiterIterator (exposes a 
 BreakIterator-like api for iterating subwords)
 the filter is much more efficient now, no cloning.
 before applying the patch, copy the existing WordDelimiterFilter to 
 OriginalWordDelimiterFilter
 the patch includes a testcase (TestWordDelimiterBWComp) which generates 
 random strings from various subword combinations.
 For each random string, it compares output against the existing 
 WordDelimiterFilter for all 512 combinations of boolean parameters.
 NOTE: due to bugs found (SOLR-1706), this currently only tests 256 of these 
 combinations. The bugs discovered in SOLR-1706 are fixed here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1710) convert worddelimiterfilter to new tokenstream API

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1710:
--

I am working with this patch with the goal of simplifying its logic and 
increasing readability.  Seems great thus far though.

 convert worddelimiterfilter to new tokenstream API
 --

 Key: SOLR-1710
 URL: https://issues.apache.org/jira/browse/SOLR-1710
 Project: Solr
  Issue Type: Improvement
  Components: Schema and Analysis
Reporter: Robert Muir
 Attachments: SOLR-1710.patch, SOLR-1710.patch


 This one was a doozy, attached is a patch to convert it to the new 
 tokenstream API.
 Some of the logic was split into WordDelimiterIterator (exposes a 
 BreakIterator-like api for iterating subwords)
 the filter is much more efficient now, no cloning.
 before applying the patch, copy the existing WordDelimiterFilter to 
 OriginalWordDelimiterFilter
 the patch includes a testcase (TestWordDelimiterBWComp) which generates 
 random strings from various subword combinations.
 For each random string, it compares output against the existing 
 WordDelimiterFilter for all 512 combinations of boolean parameters.
 NOTE: due to bugs found (SOLR-1706), this currently only tests 256 of these 
 combinations. The bugs discovered in SOLR-1706 are fixed here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1696) Deprecate old highlighting syntax and move configuration to HighlightComponent

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1696:
--

Are you planning on logging a warning if they continue to use the deprecated 
syntax?

 Deprecate old highlighting syntax and move configuration to 
 HighlightComponent
 

 Key: SOLR-1696
 URL: https://issues.apache.org/jira/browse/SOLR-1696
 Project: Solr
  Issue Type: Improvement
  Components: highlighter
Reporter: Noble Paul
 Fix For: 1.5

 Attachments: SOLR-1696.patch


 There is no reason why we should have a custom syntax for highlighter 
 configuration.
 It can be treated like any other SearchComponent and all the configuration 
 can go in there.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1699) deprecate the updateHandler configuration syntax

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1699:
--

Hi,

I like the idea of standardising the syntax in the solrconfig.xml, but I think 
this is actually not categorising the UpdateHandler correctly.  It gives the 
impression that it can respond to requests, and is just an alternative to the 
other update request handlers (XmlUpdateRequestHandlers  co), which it isn't.

 deprecate the updateHandler configuration syntax
 

 Key: SOLR-1699
 URL: https://issues.apache.org/jira/browse/SOLR-1699
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
 Fix For: 1.5


 For all practical purposes, an updatehandler is a requestHandler. We can do 
 away with a custom syntax for updatehandler
 example
 {code:xml}
 requestHandler class=solr.DirectUpdateHandler2
 
 lst name=autoCommit 
   int name=maxDocs1/int
   int name=maxTime360/int 
 /lst
 
 !-- represents a lower bound on the frequency that commits may
 occur (in seconds). NOTE: not yet implemented
 
 int name=commitIntervalLowerBound0/int
 --
   /requestHandler
 {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1586) Create Spatial Point FieldTypes

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1586:
--

Hi,

I'm not entirely clear of the outcome of the discussion re the 
SpatialTilePoint, but I would really recommend keeping this as far away from 
the user as possible.  Ideally they shouldn't have to know about it at all 
since it seems that the implementation of the spatial tiling is still heavily 
in development.  Alternatives have even been suggested that would make it 
redundant.  

I agree with the idea that to the user they should only be concerned about 
their documents have a Point.  It then frees us up to do all kinds of changes 
to the underlying logic, without the definition of their documents having to 
change.

 Create Spatial Point FieldTypes
 ---

 Key: SOLR-1586
 URL: https://issues.apache.org/jira/browse/SOLR-1586
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: examplegeopointdoc.patch.txt, SOLR-1586-geohash.patch, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112509.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.120709.geohashonly.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outarr.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outstr.patch.txt, 
 SOLR-1586.Mattmann.122609.patch.txt, SOLR-1586.patch, SOLR-1586.patch


 Per SOLR-773, create field types that hid the details of creating tiers, 
 geohash and lat/lon fields.
 Fields should take in lat/lon points in a single form, as in:
 field name=foolat lon/field

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1586) Create Spatial Point FieldTypes

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1586:
--

The alternatives I'm alluding to are the use of TrieRanges to do an efficient 
bounding box style filter instead of the tiling system.  In SOLR-773 this was 
touched on, but I never saw an outcome to that discussion.  I think it is a 
worthwhile thing to explore, even as part of the work being done here in Solr.

 Create Spatial Point FieldTypes
 ---

 Key: SOLR-1586
 URL: https://issues.apache.org/jira/browse/SOLR-1586
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: examplegeopointdoc.patch.txt, SOLR-1586-geohash.patch, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112509.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.120709.geohashonly.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outarr.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outstr.patch.txt, 
 SOLR-1586.Mattmann.122609.patch.txt, SOLR-1586.patch, SOLR-1586.patch


 Per SOLR-773, create field types that hid the details of creating tiers, 
 geohash and lat/lon fields.
 Fields should take in lat/lon points in a single form, as in:
 field name=foolat lon/field

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1586) Create Spatial Point FieldTypes

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1586:
--

Ah yes sorry TrieFields.  I don't see searching 2 fields as a downside since 
that's just an implementation detail like the Spatial Tile (which requires you 
to have upto 15 fields).  Assuming you can use the Point FieldType to index an 
x and y field, then it just becomes another option like Spatial Tile.  The fact 
they are supported out of box is part of the attraction, as it would reduce how 
much custom code has to be maintained. 

 Create Spatial Point FieldTypes
 ---

 Key: SOLR-1586
 URL: https://issues.apache.org/jira/browse/SOLR-1586
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: examplegeopointdoc.patch.txt, SOLR-1586-geohash.patch, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112509.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.120709.geohashonly.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outarr.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outstr.patch.txt, 
 SOLR-1586.Mattmann.122609.patch.txt, SOLR-1586.patch, SOLR-1586.patch


 Per SOLR-773, create field types that hid the details of creating tiers, 
 geohash and lat/lon fields.
 Fields should take in lat/lon points in a single form, as in:
 field name=foolat lon/field

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1586) Create Spatial Point FieldTypes

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1586:
--

If its not something we want to support, then thats fine.  Particularly given 
the stats Patrick has, its been clear that in those high density environments 
its not a good choice.   My original point was that this aspect of the spatial 
search is still heavily in development and I was advocating trying to reduce 
the visibility of the Spatial Tile implementation so that we are freer to do 
that development.

 Create Spatial Point FieldTypes
 ---

 Key: SOLR-1586
 URL: https://issues.apache.org/jira/browse/SOLR-1586
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: examplegeopointdoc.patch.txt, SOLR-1586-geohash.patch, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112509.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.120709.geohashonly.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outarr.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outstr.patch.txt, 
 SOLR-1586.Mattmann.122609.patch.txt, SOLR-1586.patch, SOLR-1586.patch


 Per SOLR-773, create field types that hid the details of creating tiers, 
 geohash and lat/lon fields.
 Fields should take in lat/lon points in a single form, as in:
 field name=foolat lon/field

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1586) Create Spatial Point FieldTypes

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1586:
--

Hi Grant,

Are you building the CartesianTier field type against the existing 
CartesianTier API?

 Create Spatial Point FieldTypes
 ---

 Key: SOLR-1586
 URL: https://issues.apache.org/jira/browse/SOLR-1586
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: examplegeopointdoc.patch.txt, SOLR-1586-geohash.patch, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112209.geopointonly.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112409.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.112509.geopointandgeohash.patch.txt, 
 SOLR-1586.Mattmann.120709.geohashonly.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outarr.patch.txt, 
 SOLR-1586.Mattmann.121209.geohash.outstr.patch.txt


 Per SOLR-773, create field types that hid the details of creating tiers, 
 geohash and lat/lon fields.
 Fields should take in lat/lon points in a single form, as in:
 field name=foolat lon/field

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1298:
--

Just a couple of thoughts about the implementation of this:

bq. should work with highlighting... this way people don't have to store large 
text fields if they already have them in another system. I'm not sure if 
SolrIndexSearcher is the right place for this or not though - perhaps its 
document() method should stick to just the stored fields?

From what I can see the Highlighter pulls documents from the SolrIndexSearcher 
as well through document() so the patch should already support highlighting.  
If we move the process away from the SolrIndexSearcher, which I understand the 
case for, then we need to move all components away from using document(), 
otherwise the same document could be represented in different ways depending 
on whether its retrieved via the #document() one time or via whatever way we 
build.  Equally, we need custom components to do the same.

I do like the idea of changing to a DocumentMutator which is given a context 
and is able to add/remove fields.  This will then work seamlessly with having 
the values inline with the documents.

Should I go ahead and mockup a patch for something like this?

 FunctionQuery results as pseudo-fields
 --

 Key: SOLR-1298
 URL: https://issues.apache.org/jira/browse/SOLR-1298
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch


 It would be helpful if the results of FunctionQueries could be added as 
 fields to a document. 
 Couple of options here:
 1. Run FunctionQuery as part of relevance score and add that piece to the 
 document
 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1298:
--

Hi Grant,

I certainly can.  I hadn't thought about having a function as an fl parameter 
value, but that makes alot of sense and I can support that through my work as 
well.  I'll work on extracting the code today and will get a patch here ASAP.

 FunctionQuery results as pseudo-fields
 --

 Key: SOLR-1298
 URL: https://issues.apache.org/jira/browse/SOLR-1298
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5


 It would be helpful if the results of FunctionQueries could be added as 
 fields to a document. 
 Couple of options here:
 1. Run FunctionQuery as part of relevance score and add that piece to the 
 document
 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1298) FunctionQuery results as pseudo-fields

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1298:
--

Hi Uri,

Yup the functions as fl parameters works straight away with the 
FieldValueSource so no changes required there.  I will first chuck up a patch 
without SOLR-1644 so that it can be immediately reviewed, then I'll dive into 
how to update it to 1644 and will create another patch then.

 FunctionQuery results as pseudo-fields
 --

 Key: SOLR-1298
 URL: https://issues.apache.org/jira/browse/SOLR-1298
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5


 It would be helpful if the results of FunctionQueries could be added as 
 fields to a document. 
 Couple of options here:
 1. Run FunctionQuery as part of relevance score and add that piece to the 
 document
 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1298) FunctionQuery results as pseudo-fields

[Chris Male (JIRA)]

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

Chris Male updated SOLR-1298:
-

Attachment: SOLR-1298.patch

Attaching the patch taken from my SOLR-773 patch.  Adds in a FieldValueSource 
and FieldValueSourceRegistry, changes the SolrIndexSearcher to use 
FieldValueSources when building a document, and hooks this process into the 
ReponseWriters.

 FunctionQuery results as pseudo-fields
 --

 Key: SOLR-1298
 URL: https://issues.apache.org/jira/browse/SOLR-1298
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1298.patch


 It would be helpful if the results of FunctionQueries could be added as 
 fields to a document. 
 Couple of options here:
 1. Run FunctionQuery as part of relevance score and add that piece to the 
 document
 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1298) FunctionQuery results as pseudo-fields

[Chris Male (JIRA)]

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

Chris Male updated SOLR-1298:
-

Attachment: SOLR-1298-FieldValues.patch

Attached new patch which changes the names from FieldValueSource to 
FieldValues, and FieldValueSourceRegistry to FieldValuesRegistry, to avoid 
confusion with ValueSource.

 FunctionQuery results as pseudo-fields
 --

 Key: SOLR-1298
 URL: https://issues.apache.org/jira/browse/SOLR-1298
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1298-FieldValues.patch, SOLR-1298.patch


 It would be helpful if the results of FunctionQueries could be added as 
 fields to a document. 
 Couple of options here:
 1. Run FunctionQuery as part of relevance score and add that piece to the 
 document
 2. Run the function (not really a query) during Document/Field retrieval

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1131:
--

My initial feeling is, is searching against just one field something this 
functionality needs to concern itself with? If someone creates a field of type 
Point for example, which behind the scenes is indexed as 2 fields, from a Solr 
schema.xml perspective it is just 1 field, and so it should be the same at the 
querying level.  We are trying to encapsulate the fact that the FieldType 
results in multiple fields.  This then frees us up to choose a naming 
convention that is easy for us to implement, because we don't have to concern 
users with the convention.

If someone does want to be able to search against just one field, such as maybe 
being able to find documents at a certain x coordinate, rather than an x,y 
Point, then I think we can simply recommend they index that data in a separate 
field.

 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Attachments: SOLR-1131-IndexMultipleFields.patch, SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1131:
--

Those are definitely big problems.  

The ResponseWriter problem could be simplified if they used SolrDocuments 
rather than retrieving raw Lucene Documents.  When constructing the 
SolrDocuments, which is done in cooperation with an IndexSchema instance, we 
have the information needed to bring the multiple fields together as one.  I'm 
not sure of the performance impact of doing this, but it seems like having the 
ResponseWriters retrieve the data in a single consistent fashion is a good 
thing in the long run anyway.

 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Attachments: SOLR-1131-IndexMultipleFields.patch, SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1568) Implement Cartesian Tier Filter

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1568:
--

Hi,

I'm just wondering why you have created your own TierFilter instead of using 
the CartesianShapeFilter from the Lucene spatial contrib?

Cheers

 Implement Cartesian Tier Filter
 ---

 Key: SOLR-1568
 URL: https://issues.apache.org/jira/browse/SOLR-1568
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: CartesianTierQParserPlugin.java


 Given an index with cartesian tiers, we should be able to pass in a filter 
 query that takes in the field name, lat, lon and radius and produces an 
 appropriate Filter for use by Solr.  Note, contrib/spatial has such a filter, 
 so it may just be that we need to hook in a QParserPlugin to handle it. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1302) Fun with Distances - Add Distance functions for a variety of things

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-1302:
--

Hi Grant,

What sort of performance do these functions have for calculating the distances 
for say 100k docs?

Thanks,

 Fun with Distances - Add Distance functions for a variety of things
 ---

 Key: SOLR-1302
 URL: https://issues.apache.org/jira/browse/SOLR-1302
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1302.patch, SOLR-1302.patch, SOLR-1302.patch


 There are many distance functions that are useful to have:
 1. Great Circle (lat/lon) and other geo distances
 2. Euclidean (Vector)
 3. Manhattan (Vector)
 4. Cosine (Vector)
 For the vector ones, the idea is that the fields on a document can be used to 
 determine the vector.  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-773:
-

Which solution are you referring to? My patch is a little out of sync with the 
latest Spatial Lucene code but updating is very easy.

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
 lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-773:
-

Hi Padriac,

Most of these patches, particularly the latest ones, are built against Solr 1.4 
therefore I recommend you use this version instead of 1.3.  I wouldn't 
recommend you use LocalSolr from SourceForge as it does not seem as though it 
has been updated recently.

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
 lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-773:
-

Brad,

Would you be willing to add your FunctionQuery to the issue?

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
 lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1023) StatsComponent should support dates (and other non-numeric fields)

[Chris Male (JIRA)]

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

Chris Male updated SOLR-1023:
-

Attachment: SOLR-1023.patch

I have attached a patch that adds support for String and Date fields.  To 
support these I have also made some improvements in the underlying architecture 
so that it is more extensible.  It is now possible to easy add statistics for 
other field types if desired in the future.

I have also updated the test class to include tests for String and Date fields.

 StatsComponent should support dates (and other non-numeric fields)
 --

 Key: SOLR-1023
 URL: https://issues.apache.org/jira/browse/SOLR-1023
 Project: Solr
  Issue Type: New Feature
Affects Versions: 1.4
 Environment: Mac OS 10.5, java version 1.5.0_16
Reporter: Peter Wolanin
 Fix For: 1.5

 Attachments: SOLR-1023.patch


 Currently, the StatsComponent only supports single-value numeric fields:
 http://wiki.apache.org/solr/StatsComponent
 trying to use it with a date field I get an exception like:  
 java.lang.NumberFormatException: For input string: 2009-01-27T20:04:04Z
 trying to use it with a string I get an error 400  Stats are valid for 
 single valued numeric values.
 For constructing date facets it would be very useful to be able to get the 
 minimum and maximum date from a DateField within a set of documents.  In 
 general, it could be useful to get the minimum and maximum from any field 
 type that can be compared, though that's of less importance.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1361) Incorrect javadoc on SolrInputDocument addField

[Chris Male (JIRA)]

Incorrect javadoc on SolrInputDocument addField
---

 Key: SOLR-1361
 URL: https://issues.apache.org/jira/browse/SOLR-1361
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Chris Male
Priority: Minor
 Fix For: 1.4


SolrInputDocument#addField(String, Object, float) has a comment copied from 
#clearAll().  The comment should reflect that the method adds a field.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1361) Incorrect javadoc on SolrInputDocument addField

[Chris Male (JIRA)]

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

Chris Male updated SOLR-1361:
-

Attachment: SOLR-1361.patch

 Incorrect javadoc on SolrInputDocument addField
 ---

 Key: SOLR-1361
 URL: https://issues.apache.org/jira/browse/SOLR-1361
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Chris Male
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-1361.patch


 SolrInputDocument#addField(String, Object, float) has a comment copied from 
 #clearAll().  The comment should reflect that the method adds a field.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-773:
-

From my experience more than just a FunctionQuery is required for LocalSolr to 
be efficient.  Without the Cartesian tier information that is added by the 
UpdateProcessor, you will have to calculate the distance for every single 
document in our index.  The great circle distance calculations are actually 
quite expensive and when multiplied by say 1 million documents, the query time 
will become around 2 or 3 seconds.  If you then repeat the calculation again 
for sorting on distance, then the time will be even worse.  Therefore it seems 
necessary to include some way to reduce the number of distance calculations 
that are done.

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
 lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-773) Incorporate Local Lucene/Solr

[Chris Male (JIRA)]

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

Chris Male updated SOLR-773:


Attachment: exampleSpatial.zip

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
 lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-773:
-

I have now attached an example configuration for the spatial search patch I 
added.  It contains some sample documents and the lucene spatial search jar 
that my patch is designed to integrate with.

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
 lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-773) Incorporate Local Lucene/Solr

[Chris Male (JIRA)]

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

Chris Male updated SOLR-773:


Attachment: SOLR-773-spatial_solr.patch
lucene-spatial-2.9-dev.jar

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: lucene-spatial-2.9-dev.jar, lucene.tar.gz, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr

[Chris Male (JIRA)]

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

Chris Male commented on SOLR-773:
-

I have just added a patch which adds support to Solr for the multi-threaded 
spatial search I've added in LUCENE-1732.  The performance improvements made by 
the multi-threaded search reduces the time taken to filter 1.2 million 
documents from 3s to between 500-800ms.

In addition to the support for the improved spatial search, I have changed the 
query syntax supported by Solr for spatial searches.  The syntax now uses local 
params which contain any information specific to a spatial search.  An example 
of a search using the new syntax is:

q={!spatial_tier lat=50.0 long=4.0 radius=10}*:*

Also as part of the patch, I have removed the need for a specific 
DistanceCalcuatingComponent by changing the query produced by the 
SpatialTierQueryParserPlugin to a FilteredQuery, and by introducing the notion 
of a FieldValueSource.  

FieldValueSources, which can be registered with the new 
FieldValueSourceRegistry, are used to add arbitrary information to documents as 
they are being written by ResponseWriters.  Hence a DistanceFieldValueSource is 
created and registered by the SpatialTierQueryParserPlugin so that the 
distances calculated during the spatial search can be added the resulting 
documents.  This removes the need to do the adding of the distances in a 
special component.  A useful feature of the FieldValueSources is that they can 
be controlled through fl request parameter.  This means that for spatial 
search, the distances calculated do not necessary have to be included in the 
response.

The final contribution of the patch is since the new spatial search uses 
multiple-threads through an ExecutorService, it is necessary for Solr to have 
an ExecutorService that can be configured and managed.  Consequently the patch 
includes support for defining an ExecutorService in the solrconfig.xml.  The 
ExecutorService is then cleaned up when the SolrCore it belongs to, is closed.

I am intending on creating an example configuration over the next few days, 
which will also include some example data.


 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: lucene-spatial-2.9-dev.jar, lucene.tar.gz, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
 SOLR-773.patch, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (SOLR-773) Incorporate Local Lucene/Solr

[Chris Male (JIRA)]

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

Chris Male edited comment on SOLR-773 at 7/3/09 8:28 AM:
-

I have just added a patch which adds support to Solr for the multi-threaded 
spatial search I've added in LUCENE-1732 (Note, I have attached the jar built 
using the code in the Lucene issue).  The performance improvements made by the 
multi-threaded search reduces the time taken to filter 1.2 million documents 
from 3s to between 500-800ms.

In addition to the support for the improved spatial search, I have changed the 
query syntax supported by Solr for spatial searches.  The syntax now uses local 
params which contain any information specific to a spatial search.  An example 
of a search using the new syntax is:

q={!spatial_tier lat=50.0 long=4.0 radius=10}*:*

Also as part of the patch, I have removed the need for a specific 
DistanceCalcuatingComponent by changing the query produced by the 
SpatialTierQueryParserPlugin to a FilteredQuery, and by introducing the notion 
of a FieldValueSource.  

FieldValueSources, which can be registered with the new 
FieldValueSourceRegistry, are used to add arbitrary information to documents as 
they are being written by ResponseWriters.  Hence a DistanceFieldValueSource is 
created and registered by the SpatialTierQueryParserPlugin so that the 
distances calculated during the spatial search can be added the resulting 
documents.  This removes the need to do the adding of the distances in a 
special component.  A useful feature of the FieldValueSources is that they can 
be controlled through fl request parameter.  This means that for spatial 
search, the distances calculated do not necessary have to be included in the 
response.

The final contribution of the patch is since the new spatial search uses 
multiple-threads through an ExecutorService, it is necessary for Solr to have 
an ExecutorService that can be configured and managed.  Consequently the patch 
includes support for defining an ExecutorService in the solrconfig.xml.  The 
ExecutorService is then cleaned up when the SolrCore it belongs to, is closed.

I am intending on creating an example configuration over the next few days, 
which will also include some example data.


  was (Author: cmale):
I have just added a patch which adds support to Solr for the multi-threaded 
spatial search I've added in LUCENE-1732.  The performance improvements made by 
the multi-threaded search reduces the time taken to filter 1.2 million 
documents from 3s to between 500-800ms.

In addition to the support for the improved spatial search, I have changed the 
query syntax supported by Solr for spatial searches.  The syntax now uses local 
params which contain any information specific to a spatial search.  An example 
of a search using the new syntax is:

q={!spatial_tier lat=50.0 long=4.0 radius=10}*:*

Also as part of the patch, I have removed the need for a specific 
DistanceCalcuatingComponent by changing the query produced by the 
SpatialTierQueryParserPlugin to a FilteredQuery, and by introducing the notion 
of a FieldValueSource.  

FieldValueSources, which can be registered with the new 
FieldValueSourceRegistry, are used to add arbitrary information to documents as 
they are being written by ResponseWriters.  Hence a DistanceFieldValueSource is 
created and registered by the SpatialTierQueryParserPlugin so that the 
distances calculated during the spatial search can be added the resulting 
documents.  This removes the need to do the adding of the distances in a 
special component.  A useful feature of the FieldValueSources is that they can 
be controlled through fl request parameter.  This means that for spatial 
search, the distances calculated do not necessary have to be included in the 
response.

The final contribution of the patch is since the new spatial search uses 
multiple-threads through an ExecutorService, it is necessary for Solr to have 
an ExecutorService that can be configured and managed.  Consequently the patch 
includes support for defining an ExecutorService in the solrconfig.xml.  The 
ExecutorService is then cleaned up when the SolrCore it belongs to, is closed.

I am intending on creating an example configuration over the next few days, 
which will also include some example data.

  
 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Attachments: lucene-spatial-2.9-dev.jar, lucene.tar.gz, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch,