[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there

[patrick o'leary (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795016#action_12795016
 ] 

patrick o'leary commented on SOLR-1602:
---

total +1

Makes it a pain to have to use find to code, and response seems like the right 
place for the writers. 


 

> Refactor SOLR package structure to include o.a.solr.response and move 
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
>  Issue Type: Improvement
>  Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt, 
> SOLR-1602.Mattmann.112509_02.patch.txt
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are 
> curiously located in the o.a.solr.request package. Not only is this package 
> getting big (30+ classes), a lot of them are misplaced. There should be a 
> first-class o.a.solr.response package, and the response related classes 
> should be given a home there. Patch forthcoming.

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

[patrick o'leary (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795014#action_12795014
 ] 

patrick o'leary commented on SOLR-1568:
---

I would be concerned that this starts making it more complex for users to 
implement.
we're going from  
{code}
&lat=49.45&long=-77.33&radius=10
{code}
to :
{code}
&fq={!sfilt p=49.32,-79.0 f=location dist=20}
{code}

What do you get out of it?
I remember FAST tm, a subsidiary of microsoft (think I got all that right), 
used have
{code}
geo_location:{-79.0,49.32,10)
{code}

And that was unnecessarily awkward to explain to folks, again because different 
folks viewed GIS calculations in different manors

Remember GIS is often like an Abbot and Costello sketch, who's on first, lat or 
long?
Keep it simple, and please don't obscure it

--1 

> 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
>
>
> 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] Issue Comment Edited: (SOLR-1647) Remove the option of setting solrconfig from web.xml

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795009#action_12795009
 ] 

Mark Miller edited comment on SOLR-1647 at 12/29/09 3:14 AM:
-

bq. I'm definitely not going to commit the same patch which is attached. I will 
ensure that all tests pass before this goes in.

I guess this is a communication error. I took {quote}I plan to commit this 
shortly.{quote} as "you are going to commit the current patch".

I guessed that you might do a few things before committing, but I have no way 
of knowing. When someone says that they plan to commit something shortly,
I take it to mean something along the lines of the patch posted. As you are 
missing two things that are pretty major pieces to this patch (the 
deprecation/non deprecation approach and a good workaround
for the tests), I voiced my opposition to the current approach shown. Its hard 
for me to guess what changes you will make to this patch before you commit soon 
- I have to assume when you say that you are committing shortly that perhaps 
you will address both things correctly and perhaps you won't - you could just 
commit the current patch, who knows - I can't really rely on you doing anything 
unless you post the patch first, but you mention nothing of another patch, just 
of committing. Thats why I brought up the issues that I did. I can see making 
some last minutes changes to a patch, but these two things are fairly important 
to this issue I feel, and not really last minute tweaks before a commit.

I'd like the opportunity to take a look at how you are going to address these 
two issues and (fwiw) possibly provide feedback.



  was (Author: markrmil...@gmail.com):
bq. I'm definitely not going to commit the same patch which is attached. I 
will ensure that all tests pass before this goes in.

I guess this is a communication error. I took {quote}I plan to commit this 
shortly.{quote} as "you are going to commit the current patch".

I guessed that you might do a few things before committing, but I have no way 
of knowing. When someone says that they plan to commit something shortly,
I take it to mean something along the lines of the patch posted. As you are 
missing two things that are pretty major pieces to this patch (the 
deprecation/non deprecation approach and a good workaround
for the tests), I voiced my opposition to the current approach shown. Its hard 
for me to guess what changes you will make to this patch before you commit soon 
- I have to assume when you say that you are committing shortly that perhaps 
you will address both things correctly and perhaps you won't - you could just 
commit the current patch, who knows - I can't really rely on you doing anything 
unless you post the patch first, but you mention nothing of another patch, just 
of committing. Thats why I brought up the issues that I did. I can say making 
some last minutes changes to a patch, but these two things are fairly important 
to this issue I feel, and not really last minute tweaks before a commit.

I'd like the opportunity to take a look at the how you are going to address 
these two issues and (fwiw) possibly provide feedback.


  
> Remove the option of setting solrconfig from web.xml
> 
>
> Key: SOLR-1647
> URL: https://issues.apache.org/jira/browse/SOLR-1647
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1647.patch
>
>
> with SOLR-1621 , it is not required to have an option to set solrconfig from 
> web.xml. Moreover editing web.xml means hacking solr itself. 

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

[jira] Commented: (SOLR-1647) Remove the option of setting solrconfig from web.xml

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795009#action_12795009
 ] 

Mark Miller commented on SOLR-1647:
---

bq. I'm definitely not going to commit the same patch which is attached. I will 
ensure that all tests pass before this goes in.

I guess this is a communication error. I took {quote}I plan to commit this 
shortly.{quote} as "you are going to commit the current patch".

I guessed that you might do a few things before committing, but I have no way 
of knowing. When someone says that they plan to commit something shortly,
I take it to mean something along the lines of the patch posted. As you are 
missing two things that are pretty major pieces to this patch (the 
deprecation/non deprecation approach and a good workaround
for the tests), I voiced my opposition to the current approach shown. Its hard 
for me to guess what changes you will make to this patch before you commit soon 
- I have to assume when you say that you are committing shortly that perhaps 
you will address both things correctly and perhaps you won't - you could just 
commit the current patch, who knows - I can't really rely on you doing anything 
unless you post the patch first, but you mention nothing of another patch, just 
of committing. Thats why I brought up the issues that I did. I can say making 
some last minutes changes to a patch, but these two things are fairly important 
to this issue I feel, and not really last minute tweaks before a commit.

I'd like the opportunity to take a look at the how you are going to address 
these two issues and (fwiw) possibly provide feedback.



> Remove the option of setting solrconfig from web.xml
> 
>
> Key: SOLR-1647
> URL: https://issues.apache.org/jira/browse/SOLR-1647
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1647.patch
>
>
> with SOLR-1621 , it is not required to have an option to set solrconfig from 
> web.xml. Moreover editing web.xml means hacking solr itself. 

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

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

[Grant Ingersoll (JIRA)]

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

Grant Ingersoll resolved SOLR-1131.
---

Resolution: Fixed

> 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: Schema and Analysis
>Reporter: Ryan McKinley
>Assignee: Grant Ingersoll
> Fix For: 1.5
>
> Attachments: diff.patch, SOLR-1131-IndexMultipleFields.patch, 
> SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
> SOLR-1131.patch, SOLR-1131.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-1586) Create Spatial Point FieldTypes

[Grant Ingersoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795006#action_12795006
 ] 

Grant Ingersoll commented on SOLR-1586:
---

Committed revision 894301.

> 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:
> lat lon

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

[jira] Commented: (SOLR-1647) Remove the option of setting solrconfig from web.xml

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795001#action_12795001
 ] 

Yonik Seeley commented on SOLR-1647:


bq. I'd also like to be more clear on what deprecation means in Solr - I know 
it doesn't mean deprecating and removing before a release even goes out (that 
makes no sense) - and I'm not sure if it means removing in the next dot release 
(as Ive see that occurring recently). Can someone pipe in on whether Solr has 
an (in)formal policy on when deprecations should/can be removed?

We don't really have a policy, but it's been a low priority to remove 
deprecations if they don't get in the way.  I think it would depend a lot on 
what was deprecated (how expert-level or not).

Specific to this feature,  if it isn't causing problems with development of 
other features, there's no reason to not deprecate it first.

> Remove the option of setting solrconfig from web.xml
> 
>
> Key: SOLR-1647
> URL: https://issues.apache.org/jira/browse/SOLR-1647
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1647.patch
>
>
> with SOLR-1621 , it is not required to have an option to set solrconfig from 
> web.xml. Moreover editing web.xml means hacking solr itself. 

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

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

[Grant Ingersoll (JIRA)]

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

Grant Ingersoll updated SOLR-1568:
--

Description: 
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}

  was: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. 

Summary: Implement Spatial Filter  (was: Implement Cartesian Tier 
Filter)

> 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
>
>
> 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] Commented: (SOLR-1586) Create Spatial Point FieldTypes

[Grant Ingersoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794922#action_12794922
 ] 

Grant Ingersoll commented on SOLR-1586:
---

bq. So it would be really nice if the same request would work regardless of 
which point field was being used (trie based, spacial tile, or geohash).

Agreed, how about I rename SOLR-1568 to be "Create a Spatial Filter Parser 
Plugin" or something to that effect and we handle it there?

> 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:
> lat lon

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

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794913#action_12794913
 ] 

Yonik Seeley commented on SOLR-1586:


The reason why I was asking about interface examples is that it looks like 
filtering is being considered separate (i.e. it would be up to the user to 
correlate the point field with the tile field).  While it's fine to allow the 
explicit creation of a tile filter, it doesn't seem like we should require 
clients to know all the details.

#gfilt short for geo-filter?
q=foo&fq={!gfilt p=10,20 f=store_location, 
d=1000}&sort=gdist(store_location,10,20)

So it would be really nice if the same request would work regardless of which 
point field was being used (trie based, spacial tile, or geohash).

> 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:
> lat lon

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

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

[Grant Ingersoll (JIRA)]

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

Grant Ingersoll updated SOLR-1586:
--

Attachment: SOLR-1586.patch

Renamed CartesianTierFieldType to SpatialTileField and renamed the other 
nomenclature to be called a SpatialTileField as I think the "tile" name is much 
more commonly used in the GIS communities.

> 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:
> lat lon

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

[Grant Ingersoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794842#action_12794842
 ] 

Grant Ingersoll commented on SOLR-1131:
---

Changed toMultiVS to vector(): Committed revision 894183. 

> 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: Schema and Analysis
>Reporter: Ryan McKinley
>Assignee: Grant Ingersoll
> Fix For: 1.5
>
> Attachments: diff.patch, SOLR-1131-IndexMultipleFields.patch, 
> SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
> SOLR-1131.patch, SOLR-1131.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] Updated: (SOLR-1586) Create Spatial Point FieldTypes

[Grant Ingersoll (JIRA)]

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

Grant Ingersoll updated SOLR-1586:
--

Comment: was deleted

(was: Changed toMultiVS to vector(): Committed revision 894183.)

> 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
>
>
> 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:
> lat lon

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

[jira] Commented: (SOLR-1647) Remove the option of setting solrconfig from web.xml

[Noble Paul (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794839#action_12794839
 ] 

Noble Paul commented on SOLR-1647:
--

I'm definitely not going to commit the same patch which is attached. I will 
ensure that all tests pass before this goes in.

I was trying to find what do others have to say on this.

The warning is going to go in CHANGES.TXT. Do we have to put it anywhere else?

> Remove the option of setting solrconfig from web.xml
> 
>
> Key: SOLR-1647
> URL: https://issues.apache.org/jira/browse/SOLR-1647
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1647.patch
>
>
> with SOLR-1621 , it is not required to have an option to set solrconfig from 
> web.xml. Moreover editing web.xml means hacking solr itself. 

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

[Grant Ingersoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794834#action_12794834
 ] 

Grant Ingersoll commented on SOLR-1586:
---

There is an example of what goes in the schema on this patch:
{code}


{code}

I think the filter question is best answered on SOLR-1568, but I'll give a 
brief thought.  Something like:
{code}
&fq={!tier dist=20}location:49.32,-79.0
{code}
or it could be:
{code}
&fq={!tier lat=49.32 lat=-79.0 dist=20}
{code}

I'm not sure which I prefer.

> 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
>
>
> 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:
> lat lon

-- 
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-1688) Inner class FieldCacheSources should be refactored into their own classes

[Chris A. Mattmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794833#action_12794833
 ] 

Chris A. Mattmann edited comment on SOLR-1688 at 12/28/09 4:41 PM:
---

bq. Chris, we are striving for balance and we are OK with the change to 
StrFieldSource. In this particular case, you seem to be pushing towards 
extremes in the name of consistency.

Yes, I am, because it's better to be extremely consistent when you are 
developing a code base that's seen by thousands of developers around the world.

bq. It is not a public API and I guess that at the time it was written, there 
was no reason to make it one. It was convenient or a matter of personal style 
or most likely a random choice. There is no litmus test and there does not have 
to be one.

Um, actually it _is_ a public API. ValueSource and FieldCacheSource are both 
public classes within the o.a.solr.search.function package. Anyone can write 
them. And if you're agreeing it was a random choice, why not turn it into a 
principled decision?

{quote}
Actually it is the other way round. Once you make it public, it is harder to 
maintain. All changes should then be backward compatible as far as possible. 
The bottom line is that making all of them public is not needed. Your opinion 
is that it is broken because it is not consistent. My opinion is that it is OK 
and it does not matter. We shouldn't lean towards making something a public API 
in the name of consistency.
{quote}

Actually it's not the other way around. Public APIs aren't harder to maintain. 
It's kind of a matter of debate. It's also mixing levels of granularity because 
public from an external (client) to SOLR server interface perspective is 
different from public at the code, library or function level as part of SOLR. 
Additionally, changes being backwards compatible is one of the many 
non-functional concerns -- there are others. Ease of use, portability, 
maintainability, understandability, etc.You can't have a blanket policy for 
maximizing one, without affecting the others.

Let's be clear. I'm not advocating that something be made a public API that 
_isn't_ already public. ValueSource and FieldCacheSource are public _classes_. 
And note the difference between _class_ and _API_. ValueSource and 
FieldCacheSource are not _API_ s, they are Java classes (different levels of 
granularity). 

Because of this class-level decision, the codebase itself contains inconsistent 
use of these 2 classes:

* as separate Java classes defined in a FieldType's Java file
* as Java classes defined in their own Java file that lives within 
o.a.solr.search.function

Also let's be clear also -- I never said "broken", I said "inconsistent". If 
what you're saying is that you as a SOLR committer don't care about 
inconsistency, then I'm sorry to hear that. 

{quote}
Most IDEs have a way to goto the source of a particular class, otherwise there 
is grep. The point is that many (most?) of these classes don't need to be 
modified unless in very rare cases. If it becomes a common practice to modify 
them, then there is probably something wrong with our APIs and we need to 
re-think them.
{quote}

If you're advocating using grep or using an IDE's search functionality as 
opposed to just understanding where code should be located based on principled 
architectural design, then again, I'm sorry to hear that. Especially when the 
principled design comes at 0 cost. The patch I attached didn't break anything, 
didn't change any APIs, furthermore, didn't change any Java classes, didn't 
change anything. All I did was re-organize the code to be a bit more principled 
in its organization. I can explain why I would put all the code in 
o.a.solr.search.function. Can you explain why it's not?

  was (Author: chrismattmann):
bq. Chris, we are striving for balance and we are OK with the change to 
StrFieldSource. In this particular case, you seem to be pushing towards 
extremes in the name of consistency.

Yes, I am, because it's better to be extremely consistent when you are 
developing a code base that's seen by thousands of developers around the world.

bq. It is not a public API and I guess that at the time it was written, there 
was no reason to make it one. It was convenient or a matter of personal style 
or most likely a random choice. There is no litmus test and there does not have 
to be one.

Um, actually it _is_ a public API. ValueSource and FieldCacheSource are both 
public classes within the o.a.solr.search.function package. Anyone can write 
them. And if you're agreeing it was a random choice, why not turn it into a 
principled decision?

{quote}
Actually it is the other way round. Once you make it public, it is harder to 
maintain. All changes should then be backward compatible as far as possible. 
The bottom line is that making all of them public is not needed. Your

[jira] Commented: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes

[Chris A. Mattmann (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794833#action_12794833
 ] 

Chris A. Mattmann commented on SOLR-1688:
-

bq. Chris, we are striving for balance and we are OK with the change to 
StrFieldSource. In this particular case, you seem to be pushing towards 
extremes in the name of consistency.

Yes, I am, because it's better to be extremely consistent when you are 
developing a code base that's seen by thousands of developers around the world.

bq. It is not a public API and I guess that at the time it was written, there 
was no reason to make it one. It was convenient or a matter of personal style 
or most likely a random choice. There is no litmus test and there does not have 
to be one.

Um, actually it _is_ a public API. ValueSource and FieldCacheSource are both 
public classes within the o.a.solr.search.function package. Anyone can write 
them. And if you're agreeing it was a random choice, why not turn it into a 
principled decision?

{quote}
Actually it is the other way round. Once you make it public, it is harder to 
maintain. All changes should then be backward compatible as far as possible. 
The bottom line is that making all of them public is not needed. Your opinion 
is that it is broken because it is not consistent. My opinion is that it is OK 
and it does not matter. We shouldn't lean towards making something a public API 
in the name of consistency.
{quote}

Actually it's not the other way around. Public APIs aren't harder to maintain. 
It's kind of a matter of debate. It's also mixing levels of granularity because 
public from an external (client) to SOLR server interface perspective is 
different from public at the code, library or function level as part of SOLR. 
Additionally, changes being backwards compatible is one of the many 
non-functional concerns -- there are others. Ease of use, portability, 
maintainability, understandability, etc.You can't have a blanket policy for 
maximizing one, without affecting the others.

Let's be clear. I'm not advocating that something be made a public API that 
_isn't_ already public. ValueSource and FieldCacheSource are public _classes_. 
And note the difference between _class_ and _API_. ValueSource and 
FieldCacheSource are not _API_s, they are Java classes (different levels of 
granularity). 

Because of this class-level decision, the codebase itself contains inconsistent 
use of these 2 classes:

* as separate Java classes defined in a FieldType's Java file
* as Java classes defined in their own Java file that lives within 
o.a.solr.search.function

Also let's be clear also -- I never said "broken", I said "inconsistent". If 
what you're saying is that you as a SOLR committer don't care about 
inconsistency, then I'm sorry to hear that. 

{quote}
Most IDEs have a way to goto the source of a particular class, otherwise there 
is grep. The point is that many (most?) of these classes don't need to be 
modified unless in very rare cases. If it becomes a common practice to modify 
them, then there is probably something wrong with our APIs and we need to 
re-think them.
{quote}

If you're advocating using grep or using an IDE's search functionality as 
opposed to just understanding where code should be located based on principled 
architectural design, then again, I'm sorry to hear that. Especially when the 
principled design comes at 0 cost. The patch I attached didn't break anything, 
didn't change any APIs, furthermore, didn't change any Java classes, didn't 
change anything. All I did was re-organize the code to be a bit more principled 
in its organization. I can explain why I would put all the code in 
o.a.solr.search.function. Can you explain why it's not?

> Inner class FieldCacheSources should be refactored into their own classes
> -
>
> Key: SOLR-1688
> URL: https://issues.apache.org/jira/browse/SOLR-1688
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 1.4
> Environment: indep. of env.
>Reporter: Chris A. Mattmann
> Fix For: 1.5
>
> Attachments: SOLR-1688.Mattmann.122609.patch.txt
>
>
> While working on SOLR-1586 I noticed that outside of class level access (or 
> package level), you can't really reference FieldCacheSources that are defined 
> inside of their FieldType constituents (e.g., in the case of StrFieldSource 
> as defined in StrField). What's more troubling is that the 
> FieldType/FieldCacheSources are defined in an inconsistent fashion: some are 
> done as inner classes, e.g., StrFieldSource and SortableFloatFieldSource, 
> while others are defined as individual classes (e.g., FloatFIeldSource). This 
> patch will make them all consistent and define each FieldCacheSource as an 
>

[spatial] FYI: Cartesian Tiers nomenclature discussion on gene...@l.a.o

[Grant Ingersoll]

FYI, I just brought up a discussion on what to call "Cartesian Tiers" over on 
gene...@lucene.apache.org (it pertains to both Lucene and Solr).  If you are 
interested, please see the discussion over there and respond to that thread and 
not this one.

Thanks,
Grant

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

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794823#action_12794823
 ] 

Yonik Seeley commented on SOLR-1586:


bq. > How will it be used?
bq. It's a common GIS technique

I meant as it pertains to Solr... what will one put in their schema and then 
what will an example query look like that does both a filter and a sort by 
distance?  Or is that out of scope for this issue?


> 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
>
>
> 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:
> lat lon

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

[Grant Ingersoll (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794818#action_12794818
 ] 

Grant Ingersoll commented on SOLR-1586:
---

Changed toMultiVS to vector(): Committed revision 894183.

> 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
>
>
> 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:
> lat lon

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

Re: [Solr Wiki] Update of "FunctionQuery" by GrantIngersoll

[Grant Ingersoll]

On Dec 27, 2009, at 11:13 AM, Yonik Seeley wrote:

> On Sun, Dec 27, 2009 at 7:09 AM, Grant Ingersoll  wrote:
>> 
>> On Dec 24, 2009, at 5:11 PM, Yonik Seeley wrote:
>> 
>>> I've noticed that the docs for geo related functions have introduced
>>> the notion of ValueSource.  That's at the Java level, and in the past
>>> I've tried to keep http://wiki.apache.org/solr/FunctionQuery
>>> completely away from that.
>>> 
>> 
>> Feel free to reword into something that describes aggregating together 
>> multiple of these "thingies" into a single multi-"thingy".
> 
> A function can be:
> - a constant
> - a field
> - a function
> 
> Now that a concept of multiple values per document has been added,
> perhaps "vector"?
> So instead of toMultiVS(x,y,z). perhaps vector(x,y,z)?  Or if not
> that, perhaps multi(x,y,z)

Whew.  I'm horrible at naming, and vector sounds much better!  I'll make the 
change in the code and on the wiki.

[jira] Commented: (SOLR-1647) Remove the option of setting solrconfig from web.xml

[Mark Miller (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794806#action_12794806
 ] 

Mark Miller commented on SOLR-1647:
---

bq. But the question is do we have to be that strict about everything?

Personally, I would say no, we don't (and many times we have not been). I'm not 
-1'ing the removal of this. I think we should keep it and say its going away 
first, but if we didn't, I wouldn't be too upset about it.

The weight of my opposition comes from: you said your about to commit it but 
there is no evidence of what your going to do about warning users - you are 
removing a feature some may currently be counting on - and there is no work 
around for the tests you are breaking that rely on this feature. One fails, and 
others that count on it that don't fail now, will confuse people when they try 
and change the config for the tests, but the specified config is not actually 
being used.

> Remove the option of setting solrconfig from web.xml
> 
>
> Key: SOLR-1647
> URL: https://issues.apache.org/jira/browse/SOLR-1647
> Project: Solr
>  Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1647.patch
>
>
> with SOLR-1621 , it is not required to have an option to set solrconfig from 
> web.xml. Moreover editing web.xml means hacking solr itself. 

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

Build failed in Hudson: Solr-trunk #1015

[Apache Hudson Server]

See 

--
[...truncated 4395 lines...]
[junit] Running 
org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 12.927 sec
[junit] Test 
org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest FAILED
[junit] Running 
org.apache.solr.client.solrj.embedded.LargeVolumeEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.53 sec
[junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 10.407 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.737 sec
[junit] Running org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.635 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 10.726 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 30.878 sec
[junit] Running org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
[junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 53.55 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 42.556 sec
[junit] Running org.apache.solr.client.solrj.embedded.TestSolrProperties
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.109 sec
[junit] Running org.apache.solr.client.solrj.request.TestUpdateRequestCodec
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.746 sec
[junit] Running 
org.apache.solr.client.solrj.response.AnlysisResponseBaseTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.271 sec
[junit] Running 
org.apache.solr.client.solrj.response.DocumentAnalysisResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.731 sec
[junit] Running 
org.apache.solr.client.solrj.response.FieldAnalysisResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.452 sec
[junit] Running org.apache.solr.client.solrj.response.QueryResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.95 sec
[junit] Running org.apache.solr.client.solrj.response.TermsResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.044 sec
[junit] Running org.apache.solr.client.solrj.response.TestSpellCheckResponse
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 14.051 sec
[junit] Running org.apache.solr.client.solrj.util.ClientUtilsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.42 sec
[junit] Running org.apache.solr.common.SolrDocumentTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.072 sec
[junit] Running org.apache.solr.common.params.ModifiableSolrParamsTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.435 sec
[junit] Running org.apache.solr.common.params.SolrParamTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.56 sec
[junit] Running org.apache.solr.common.util.ContentStreamTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.536 sec
[junit] Running org.apache.solr.common.util.DOMUtilTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.799 sec
[junit] Running org.apache.solr.common.util.FileUtilsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.397 sec
[junit] Running org.apache.solr.common.util.IteratorChainTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.397 sec
[junit] Running org.apache.solr.common.util.NamedListTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.486 sec
[junit] Running org.apache.solr.common.util.TestFastInputStream
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.478 sec
[junit] Running org.apache.solr.common.util.TestHash
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.762 sec
[junit] Running org.apache.solr.common.util.TestNamedListCodec
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 4.976 sec
[junit] Running org.apache.solr.common.util.TestXMLEscaping
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.522 sec
[junit] Running org.apache.solr.core.AlternateDirectoryTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.459 sec
[junit] Running org.apache.solr.core.AlternateIndexReaderTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.996 sec
[junit] Running org.apache.solr.core

Solr nightly build failure

[solr-dev]

init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[mkdir] Created dir: /tmp/apache-solr-nightly/build/web

compile-solrj:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj
[javac] Compiling 88 source files to /tmp/apache-solr-nightly/build/solrj
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compile:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/solr
[javac] Compiling 410 source files to /tmp/apache-solr-nightly/build/solr
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compileTests:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/tests
[javac] Compiling 208 source files to /tmp/apache-solr-nightly/build/tests
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

dist-contrib:

init:
[mkdir] Created dir: 
/tmp/apache-solr-nightly/contrib/clustering/build/classes
[mkdir] Created dir: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads
[mkdir] Created dir: /tmp/apache-solr-nightly/build/docs/api

init-forrest-entities:

compile-solrj:

compile:
[javac] Compiling 1 source file to /tmp/apache-solr-nightly/build/solr
[javac] Note: 
/tmp/apache-solr-nightly/src/java/org/apache/solr/search/DocSetHitCollector.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

make-manifest:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/META-INF

proxy.setup:

check-files:

get-colt:
  [get] Getting: 
http://repo1.maven.org/maven2/colt/colt/1.2.0/colt-1.2.0.jar
  [get] To: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads/colt-1.2.0.jar

get-pcj:
  [get] Getting: http://repo1.maven.org/maven2/pcj/pcj/1.2/pcj-1.2.jar
  [get] To: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads/pcj-1.2.jar

get-nni:
  [get] Getting: 
http://download.carrot2.org/maven2/org/carrot2/nni/1.0.0/nni-1.0.0.jar
  [get] To: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads/nni-1.0.0.jar

get-simple-xml:
  [get] Getting: 
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/simpleframework/simple-xml/1.7.3/simple-xml-1.7.3.jar
  [get] To: 
/tmp/apache-solr-nightly/contrib/clustering/lib/downloads/simple-xml-1.7.3.jar

get-libraries:

compile:
[javac] Compiling 7 source files to 
/tmp/apache-solr-nightly/contrib/clustering/build/classes
[javac] Note: 
/tmp/apache-solr-nightly/contrib/clustering/src/main/java/org/apache/solr/handler/clustering/carrot2/CarrotClusteringEngine.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

build:
  [jar] Building jar: 
/tmp/apache-solr-nightly/contrib/clustering/build/apache-solr-clustering-1.5-dev.jar

dist:
 [copy] Copying 1 file to /tmp/apache-solr-nightly/dist

init:
[mkdir] Created dir: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/classes

init-forrest-entities:

compile-solrj:

compile:
[javac] Compiling 1 source file to /tmp/apache-solr-nightly/build/solr
[javac] Note: 
/tmp/apache-solr-nightly/src/java/org/apache/solr/search/DocSetHitCollector.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.

make-manifest:

compile:
[javac] Compiling 46 source files to 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/classes
[javac] Note: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DocBuilder.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

compileExtras:
[mkdir] Created dir: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/extras/classes
[javac] Compiling 2 source files to 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/extras/classes
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.

build:
  [jar] Building jar: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/apache-solr-dataimporthandler-1.5-dev.jar
  [jar] Building jar: 
/tmp/apache-solr-nightly/contrib/dataimporthandler/target/apache-solr-dataimporthandler-extras-1.5

[jira] Commented: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes

[Shalin Shekhar Mangar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794782#action_12794782
 ] 

Shalin Shekhar Mangar commented on SOLR-1688:
-

{quote}
IMO, most of these should remain implementation details (i.e. not public)... 
they weren't thought out in sufficient detail to support as public classes (and 
there has been little reason to do so).
If we need StrValueSource to be public for another issue, then we should limit 
the change to that. 
{quote}

+1

As they say, lets not fix what ain't broken.

{quote}
If they are defined as a "core" data structure part of the JDK, then I would 
say yes. It's not as black and white of a line as you make it out to be. You 
can have SOLR be entirely a plugin-based system, with nothing but configuration 
inside of SVN, or you can have every piece of code that interacts with SOLR be 
inside the SOLR SVN. Neither solution will work, you have to strike a balance. 
The same applies for code organization and using absolutes or extremes doesn't 
really illustrate much.
{quote}

Chris, we are striving for balance and we are OK with the change to 
StrFieldSource. In this particular case, you seem to be pushing towards 
extremes in the name of consistency.

{quote}
Can you tell me the reason that e.g., StrFieldSource exists inside of StrField 
while DoubleFieldSource exists outside of DoubleField? Or why the other 4 or 5 
FieldSources that are defined inside of their own java file exist there, while 
the other 4 or 5 defined inside of the FieldType's java file exist there? 
What's the litmus test?
{quote}

It is not a public API and I guess that at the time it was written, there was 
no reason to make it one. It was convenient or a matter of personal style or 
most likely a random choice. There is no litmus test and there does not have to 
be one.

{quote}
Because it's more consistent, and thus, more maintainable.
{quote}

Actually it is the other way round. Once you make it public, it is harder to 
maintain. All changes should then be backward compatible as far as possible. 
The bottom line is that making all of them public is not needed. Your opinion 
is that it is broken because it is not consistent. My opinion is that it is OK 
and it does not matter. We shouldn't lean towards making something a public API 
in the name of consistency.

{quote}
Because when you tell someone to modify one of the core FieldSources or 
ValueSources, they know where to look instead of, "oh is this one inside of a 
class inside of o.a.solr.schema, or is this one in the o.a.solr.search.function 
package"?
{quote}

Most IDEs have a way to goto the source of a particular class, otherwise there 
is grep. The point is that many (most?) of these classes don't need to be 
modified unless in very rare cases. If it becomes a common practice to modify 
them, then there is probably something wrong with our APIs and we need to 
re-think them.

> Inner class FieldCacheSources should be refactored into their own classes
> -
>
> Key: SOLR-1688
> URL: https://issues.apache.org/jira/browse/SOLR-1688
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Affects Versions: 1.4
> Environment: indep. of env.
>Reporter: Chris A. Mattmann
> Fix For: 1.5
>
> Attachments: SOLR-1688.Mattmann.122609.patch.txt
>
>
> While working on SOLR-1586 I noticed that outside of class level access (or 
> package level), you can't really reference FieldCacheSources that are defined 
> inside of their FieldType constituents (e.g., in the case of StrFieldSource 
> as defined in StrField). What's more troubling is that the 
> FieldType/FieldCacheSources are defined in an inconsistent fashion: some are 
> done as inner classes, e.g., StrFieldSource and SortableFloatFieldSource, 
> while others are defined as individual classes (e.g., FloatFIeldSource). This 
> patch will make them all consistent and define each FieldCacheSource as an 
> outside class, present in o.a.solr.search.function.

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