[jira] Commented: (SOLR-1568) Implement Spatial Filter
[
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12853556#action_12853556
]
Chris A. Mattmann commented on SOLR-1568:
-
+1 on the latest patch with the following caveat:
Why not put:
{code}
public static final double DEGREES_TO_RADIANS = Math.PI / 180.0;
public static final double RADIANS_TO_DEGREES = 180.0 / Math.PI;
+ public static final double DEG_45 = Math.PI / 4.0;
+ public static final double DEG_225 = 5 * DEG_45;
+ public static final double DEG_90 = Math.PI / 2;
+ public static final double DEG_180 = Math.PI;
+ public static final double SIN_45 = Math.sin(DEG_45);
{code}
into solr/src/java/org/apache/solr/search/function/distance/Constants.java,
and then make DistanceUtils implement (or static import) those constants?
Cheers,
Chris
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,
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] Commented: (SOLR-1568) Implement Spatial Filter
[
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12843883#action_12843883
]
Chris A. Mattmann commented on SOLR-1568:
-
Hey Grant:
I'll take a look at your latest patch and try to iterate on it (at least make
sure it compiles, and take a pass with javadocs, run the unit tests, etc.).
Should have something up in the next few hours.
Cheers,
Chris
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.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] Updated: (SOLR-1568) Implement Spatial Filter
[
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris A. Mattmann updated SOLR-1568:
Attachment: SOLR-1568.Mattmann.031010.patch.txt
OK, this guy compiles, and I tried to guess in a couple areas (e.g., please
look at Haversine) where variables were missing. One nice thing you can take
out of this is the normalize functions for lat and lon in DistanceUtils --
those will probably be generally useful.
I'll also look to bring some of this over to SIS, as we start to flesh it out.
I saw an error during unit tests in
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest, but it seems
unrelated (so suspicious -- is this a real bug?):
[chipotle:solr/build/test-results] mattmann% more
TEST-org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.txt
Testsuite: org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
Testcase: testContentStreamRequest took 0.003 sec
Caused an ERROR
Forked Java VM exited abnormally. Please note the time in the report does not re
flect the time until the VM exit.
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please n
ote the time in the report does not reflect the time until the VM exit.
[chipotle:solr/build/test-results] mattmann%
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
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-1568) Implement Spatial Filter
[
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12843902#action_12843902
]
Chris A. Mattmann edited comment on SOLR-1568 at 3/11/10 4:28 AM:
--
OK, this guy compiles, and I tried to guess in a couple areas (e.g., please
look at Haversine) where variables were missing. One nice thing you can take
out of this is the normalize functions for lat and lon in DistanceUtils --
those will probably be generally useful.
I'll also look to bring some of this over to SIS, as we start to flesh it out.
I saw an error during unit tests in
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest, but it seems
unrelated (so suspicious -- is this a real bug?):
{noformat}
[chipotle:solr/build/test-results] mattmann% more
TEST-org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.txt
Testsuite: org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
Testcase: testContentStreamRequest took 0.003 sec
Caused an ERROR
Forked Java VM exited abnormally. Please note the time in the report does not re
flect the time until the VM exit.
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please n
ote the time in the report does not reflect the time until the VM exit.
[chipotle:solr/build/test-results] mattmann%
{noformat}
was (Author: chrismattmann):
OK, this guy compiles, and I tried to guess in a couple areas (e.g., please
look at Haversine) where variables were missing. One nice thing you can take
out of this is the normalize functions for lat and lon in DistanceUtils --
those will probably be generally useful.
I'll also look to bring some of this over to SIS, as we start to flesh it out.
I saw an error during unit tests in
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest, but it seems
unrelated (so suspicious -- is this a real bug?):
[chipotle:solr/build/test-results] mattmann% more
TEST-org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest.txt
Testsuite: org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
Testcase: testContentStreamRequest took 0.003 sec
Caused an ERROR
Forked Java VM exited abnormally. Please note the time in the report does not re
flect the time until the VM exit.
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please n
ote the time in the report does not reflect the time until the VM exit.
[chipotle:solr/build/test-results] mattmann%
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
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] Updated: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1602: Attachment: SOLR-1602.Mattmann.wrapup.031010.patch.txt - so I finally found that bit of time I was looking for to wrap this up. Ryan, this should take care of 1 and 2 that we were waiting on to close this out. My +1 to wrap it up. 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 Assignee: Ryan McKinley Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, SOLR-1602.Mattmann.wrapup.031010.patch.txt, upgrade_solr_config 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-1642) Change name of SOLR749Test
[ https://issues.apache.org/jira/browse/SOLR-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12843916#action_12843916 ] Chris A. Mattmann commented on SOLR-1642: - Guys, any feedback on this? Change name of SOLR749Test -- Key: SOLR-1642 URL: https://issues.apache.org/jira/browse/SOLR-1642 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 1.3, 1.4 Environment: My local MacBook pro. Reporter: Chris A. Mattmann Priority: Trivial Fix For: 1.5 Attachments: SOLR-1642.Mattmann.121009.patch.txt The test class named SOLR749Test is inconsistent with all of the rest of the unit tests, which aren't tied to their JIRA issue names. Some examples of best practices: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html http://blog.taragana.com/index.php/archive/java-unit-testing-best-practices/ http://junit.sourceforge.net/doc/faq/faq.htm#best -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes
[ https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12843924#action_12843924 ] Chris A. Mattmann commented on SOLR-1688: - Any comments on this guys? Compromise? Standoff? White flag? :P 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.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829087#action_12829087 ] Chris A. Mattmann commented on SOLR-1602: - Hey Erik: You just forgot to press the easy button! :P http://bit.ly/zog3s Cheers, Chris 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 Assignee: Ryan McKinley Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config 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] Created: (SOLR-1733) Allow specification of date output format on date faceting
Allow specification of date output format on date faceting
--
Key: SOLR-1733
URL: https://issues.apache.org/jira/browse/SOLR-1733
Project: Solr
Issue Type: Improvement
Components: SearchComponents - other
Environment: my local mac book pro.
Reporter: Chris A. Mattmann
Fix For: 1.5
It would be really great if the facet component allowed the specification of
the date output format, so that e.g., if I wanted to facet by month, I could
also specify what the resultant date facets look like. In other words, a facet
query like this:
http://localhost:8993/solr/select/?q=*:*version=2.2start=0rows=146indent=onfacet=onfacet.date=startdatefacet.date.start=NOW/YEAR-50YEARSfacet.date.end=NOWfacet.date.gap=%2B1MONTHfacet.date.output=yy-MM-dd
Showed output like:
{code:xml}
lst name=facet_dates
lst name=startdate
int name=1960-01-010/int
int name=1960-02-011/int
int name=1960-03-010/int
int name=1960-04-010/int
int name=1960-05-012/int
...
/lst
/lst
{code}
Patch forthcoming that implements this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1725) Script based UpdateRequestProcessorFactory
[
https://issues.apache.org/jira/browse/SOLR-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804106#action_12804106
]
Chris A. Mattmann commented on SOLR-1725:
-
oh and one other thing -- I _really_ like this patch, Uri! I'm looking to
integrate it into a data processing project here at JPL. Great idea!
Script based UpdateRequestProcessorFactory
--
Key: SOLR-1725
URL: https://issues.apache.org/jira/browse/SOLR-1725
Project: Solr
Issue Type: New Feature
Components: update
Affects Versions: 1.4
Reporter: Uri Boness
Attachments: SOLR-1725.patch, SOLR-1725.patch, SOLR-1725.patch,
SOLR-1725.patch
A script based UpdateRequestProcessorFactory (Uses JDK6 script engine
support). The main goal of this plugin is to be able to configure/write
update processors without the need to write and package Java code.
The update request processor factory enables writing update processors in
scripts located in {{solr.solr.home}} directory. The functory accepts one
(mandatory) configuration parameter named {{scripts}} which accepts a
comma-separated list of file names. It will look for these files under the
{{conf}} directory in solr home. When multiple scripts are defined, their
execution order is defined by the lexicographical order of the script file
name (so {{scriptA.js}} will be executed before {{scriptB.js}}).
The script language is resolved based on the script file extension (that is,
a *.js files will be treated as a JavaScript script), therefore an extension
is mandatory.
Each script file is expected to have one or more methods with the same
signature as the methods in the {{UpdateRequestProcessor}} interface. It is
*not* required to define all methods, only those hat are required by the
processing logic.
The following variables are define as global variables for each script:
* {{req}} - The SolrQueryRequest
* {{rsp}}- The SolrQueryResponse
* {{logger}} - A logger that can be used for logging purposes in the script
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1725) Script based UpdateRequestProcessorFactory
[
https://issues.apache.org/jira/browse/SOLR-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804105#action_12804105
]
Chris A. Mattmann commented on SOLR-1725:
-
Is there any reason for SOLR _not_ to move to JDK 1.6?
Script based UpdateRequestProcessorFactory
--
Key: SOLR-1725
URL: https://issues.apache.org/jira/browse/SOLR-1725
Project: Solr
Issue Type: New Feature
Components: update
Affects Versions: 1.4
Reporter: Uri Boness
Attachments: SOLR-1725.patch, SOLR-1725.patch, SOLR-1725.patch,
SOLR-1725.patch
A script based UpdateRequestProcessorFactory (Uses JDK6 script engine
support). The main goal of this plugin is to be able to configure/write
update processors without the need to write and package Java code.
The update request processor factory enables writing update processors in
scripts located in {{solr.solr.home}} directory. The functory accepts one
(mandatory) configuration parameter named {{scripts}} which accepts a
comma-separated list of file names. It will look for these files under the
{{conf}} directory in solr home. When multiple scripts are defined, their
execution order is defined by the lexicographical order of the script file
name (so {{scriptA.js}} will be executed before {{scriptB.js}}).
The script language is resolved based on the script file extension (that is,
a *.js files will be treated as a JavaScript script), therefore an extension
is mandatory.
Each script file is expected to have one or more methods with the same
signature as the methods in the {{UpdateRequestProcessor}} interface. It is
*not* required to define all methods, only those hat are required by the
processing logic.
The following variables are define as global variables for each script:
* {{req}} - The SolrQueryRequest
* {{rsp}}- The SolrQueryResponse
* {{logger}} - A logger that can be used for logging purposes in the script
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1591) XMLWriter#writeAttr silently ignores null attribute values
[
https://issues.apache.org/jira/browse/SOLR-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799784#action_12799784
]
Chris A. Mattmann commented on SOLR-1591:
-
{quote}
shrugs - the example I gave was meant to show how defining the function to work
for null can simplify code that calls the function. What didn't you
understand about that?
{quote}
Well I understood your comment I was just confused as to how it's any better I
guess. You showed this as a simplification that having the silently ignored
null allows:
{code}
writeAttr(foo, map.get(foo));
writeAttr(foo, map.get(bar));
{code}
Agreed, it's a bit prettier than this:
{code}
String fooVal = map.get(foo);
if (fooVal != null) {
writeAttr(foo, fooVal);
}
String barVal= map.get(bar);
if (barVal!= null) {
writeAttr(bar, barVal);
}
...
{code}
But what about this?
{code}
if(map.get(foo)) != null writeAttr(foo, map.get(foo));
if(map.get(bar)) != null writeAttr(bar, map.get(bar));
{code}
{quote}
No, not if the function is well defined for a null value.
{quote}
It can be as well defined as you'd like but in the end it's a no-op and a
waste, and more importantly it's a silent waste, right?
{quote}
And if we moved the null check to the callers, I'd argue that the null check
should be entirely left out of writeAttr - skip the extra code and let the NPE
happen naturally.
{quote}
+1 to this. What do you think?
Cheers,
Chris
XMLWriter#writeAttr silently ignores null attribute values
--
Key: SOLR-1591
URL: https://issues.apache.org/jira/browse/SOLR-1591
Project: Solr
Issue Type: Bug
Affects Versions: 1.4
Environment: My local MacBook pro laptop.
Reporter: Chris A. Mattmann
Priority: Minor
Fix For: 1.5
Attachments: SOLR-1591.Mattmann.112209.patch.txt
XMLWriter#writeAttr checks for val == null, and if so, does nothing. Instead
of doing nothing, it could leverage its method signature, and throw an
IOException declaring that the value provided is null. Patch, attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1591) XMLWriter#writeAttr silently ignores null attribute values
[
https://issues.apache.org/jira/browse/SOLR-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799792#action_12799792
]
Chris A. Mattmann commented on SOLR-1591:
-
bq. Why are you arguing performance if you're going to look up the key twice?
It's an order of magnitude more expensive.
Just copied it through from your example. Your point was to show it was a bit
messier to do the check and my point was to show it's all about how you
organize that messiness.
bq. This is such a trivial issue though... we really shouldn't be wasting
breath on it.
Fantastic point. You threw up a suggestion:
{quote}
And if we moved the null check to the callers, I'd argue that the null check
should be entirely left out of writeAttr - skip the extra code and let the NPE
happen naturally.
{quote}
That sounds like a plan, +1 to that. Then, we can stop wasting time on this and
move on to (more) interesting stuff...
XMLWriter#writeAttr silently ignores null attribute values
--
Key: SOLR-1591
URL: https://issues.apache.org/jira/browse/SOLR-1591
Project: Solr
Issue Type: Improvement
Affects Versions: 1.1.0
Environment: My local MacBook pro laptop.
Reporter: Chris A. Mattmann
Priority: Minor
Attachments: SOLR-1591.Mattmann.112209.patch.txt
XMLWriter#writeAttr checks for val == null, and if so, does nothing. Instead
of doing nothing, it could leverage its method signature, and throw an
IOException declaring that the value provided is null. Patch, attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1591) XMLWriter#writeAttr silently ignores null attribute values
[ https://issues.apache.org/jira/browse/SOLR-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1591: Component/s: Response Writers XMLWriter#writeAttr silently ignores null attribute values -- Key: SOLR-1591 URL: https://issues.apache.org/jira/browse/SOLR-1591 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.1.0 Environment: My local MacBook pro laptop. Reporter: Chris A. Mattmann Priority: Minor Attachments: SOLR-1591.Mattmann.112209.patch.txt XMLWriter#writeAttr checks for val == null, and if so, does nothing. Instead of doing nothing, it could leverage its method signature, and throw an IOException declaring that the value provided is null. Patch, attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1591) XMLWriter#writeAttr silently ignores null attribute values
[ https://issues.apache.org/jira/browse/SOLR-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799604#action_12799604 ] Chris A. Mattmann commented on SOLR-1591: - Hey Yonik: Thanks for your last comment, but I'm still confused. This is a wasted method call. At the very least, the method should log a message saying a null attribute was attempted to be written. Otherwise you have no record that the function was even called at all, which makes it hard to debug and track things down. I'd favor an exception to be thrown and a null check explicitly (at the expense of the additional lines of code) since it's more verbose and explicit rather than implicit. Thoughts? Anyone? Cheers, Chris XMLWriter#writeAttr silently ignores null attribute values -- Key: SOLR-1591 URL: https://issues.apache.org/jira/browse/SOLR-1591 Project: Solr Issue Type: Bug Affects Versions: 1.4 Environment: My local MacBook pro laptop. Reporter: Chris A. Mattmann Priority: Minor Fix For: 1.5 Attachments: SOLR-1591.Mattmann.112209.patch.txt XMLWriter#writeAttr checks for val == null, and if so, does nothing. Instead of doing nothing, it could leverage its method signature, and throw an IOException declaring that the value provided is null. Patch, attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes
[ https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799618#action_12799618 ] Chris A. Mattmann commented on SOLR-1688: - Hi All, Yonik, what do you think on this one? The patch I put up at least follows a single policy and has rationale rather than the existing code which does not (see comments above). What's the compromise here? Let's get this cleaned up! :) Cheers, Chris 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.
[jira] Commented: (SOLR-1642) Change name of SOLR749Test
[ https://issues.apache.org/jira/browse/SOLR-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799619#action_12799619 ] Chris A. Mattmann commented on SOLR-1642: - Any takers on this one? Hoss? Others? Cheers, Chris Change name of SOLR749Test -- Key: SOLR-1642 URL: https://issues.apache.org/jira/browse/SOLR-1642 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 1.3, 1.4 Environment: My local MacBook pro. Reporter: Chris A. Mattmann Priority: Trivial Fix For: 1.5 Attachments: SOLR-1642.Mattmann.121009.patch.txt The test class named SOLR749Test is inconsistent with all of the rest of the unit tests, which aren't tied to their JIRA issue names. Some examples of best practices: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html http://blog.taragana.com/index.php/archive/java-unit-testing-best-practices/ http://junit.sourceforge.net/doc/faq/faq.htm#best -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1591) XMLWriter#writeAttr silently ignores null attribute values
[ https://issues.apache.org/jira/browse/SOLR-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799621#action_12799621 ] Chris A. Mattmann commented on SOLR-1591: - It may work as designed Noble, but as designed, it's a wasted function call. SOLR is all about performance. Why waste a function call here? XMLWriter#writeAttr silently ignores null attribute values -- Key: SOLR-1591 URL: https://issues.apache.org/jira/browse/SOLR-1591 Project: Solr Issue Type: Bug Affects Versions: 1.4 Environment: My local MacBook pro laptop. Reporter: Chris A. Mattmann Priority: Minor Fix For: 1.5 Attachments: SOLR-1591.Mattmann.112209.patch.txt XMLWriter#writeAttr checks for val == null, and if so, does nothing. Instead of doing nothing, it could leverage its method signature, and throw an IOException declaring that the value provided is null. Patch, attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799626#action_12799626
]
Chris A. Mattmann commented on SOLR-1602:
-
Hi Ryan:
Thanks so much for moving on this!
Patch forthcoming that addresses:
{quote}
1. error messages
2. CHANGES.txt
{quote}
I think you handled 3, right?
Thanks, again and I'll try and throw up the patch for 1/2 tomorrow morning
pacific time.
Cheers,
Chris
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
Assignee: Ryan McKinley
Fix For: 1.5
Attachments: SOLR-1602.Mattmann.112509.patch.txt,
SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
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-1591) XMLWriter#writeAttr silently ignores null attribute values
[
https://issues.apache.org/jira/browse/SOLR-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799628#action_12799628
]
Chris A. Mattmann commented on SOLR-1591:
-
Hey Noble:
Here are the disadvantages:
{quote}
* null values are rare .optimizing for cornercases is not a good idea
{quote}
It's not a corner case: much of the SOLR XML response calls this function for a
null value (e.g., any tag without an explicit name attribute, which are e.g.,
all the docs in a result set, which can be large, depending on the start/end
row params.
{quote}
* the cost of a function call is almost zilch. it is not even measurable
{quote}
cost(function) cost(comparison)
XMLWriter#writeAttr silently ignores null attribute values
--
Key: SOLR-1591
URL: https://issues.apache.org/jira/browse/SOLR-1591
Project: Solr
Issue Type: Bug
Affects Versions: 1.4
Environment: My local MacBook pro laptop.
Reporter: Chris A. Mattmann
Priority: Minor
Fix For: 1.5
Attachments: SOLR-1591.Mattmann.112209.patch.txt
XMLWriter#writeAttr checks for val == null, and if so, does nothing. Instead
of doing nothing, it could leverage its method signature, and throw an
IOException declaring that the value provided is null. Patch, attached.
--
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-1591) XMLWriter#writeAttr silently ignores null attribute values
[
https://issues.apache.org/jira/browse/SOLR-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799628#action_12799628
]
Chris A. Mattmann edited comment on SOLR-1591 at 1/13/10 7:13 AM:
--
Hey Noble:
Here are the disadvantages:
{quote}
* null values are rare .optimizing for cornercases is not a good idea
{quote}
It's not a corner case: much of the SOLR XML response calls this function for a
null value (e.g., any tag without an explicit name attribute, which are e.g.,
all the docs in a result set, which can be large, depending on the start/end
row params).
{quote}
* the cost of a function call is almost zilch. it is not even measurable
{quote}
cost(function) cost(comparison)
Cheers,
Chris
was (Author: chrismattmann):
Hey Noble:
Here are the disadvantages:
{quote}
* null values are rare .optimizing for cornercases is not a good idea
{quote}
It's not a corner case: much of the SOLR XML response calls this function for a
null value (e.g., any tag without an explicit name attribute, which are e.g.,
all the docs in a result set, which can be large, depending on the start/end
row params.
{quote}
* the cost of a function call is almost zilch. it is not even measurable
{quote}
cost(function) cost(comparison)
XMLWriter#writeAttr silently ignores null attribute values
--
Key: SOLR-1591
URL: https://issues.apache.org/jira/browse/SOLR-1591
Project: Solr
Issue Type: Bug
Affects Versions: 1.4
Environment: My local MacBook pro laptop.
Reporter: Chris A. Mattmann
Priority: Minor
Fix For: 1.5
Attachments: SOLR-1591.Mattmann.112209.patch.txt
XMLWriter#writeAttr checks for val == null, and if so, does nothing. Instead
of doing nothing, it could leverage its method signature, and throw an
IOException declaring that the value provided is null. Patch, attached.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797123#action_12797123 ] Chris A. Mattmann commented on SOLR-1602: - Hi All: In the interest of moving forward on this, I'll go with option B, as I think I've made my point (as have others) and this is something important to get wrapped up IMO. I'd like to have an understanding though that in the next release of SOLR (1.6?) the deprecated classes can go away. Or, as Uri and Patrick pointed out, if the release cycle picks up then at worst 1.7. Thanks to everyone for their thoughtful comments. I am going to throw up a new patch that: 1. replaces the content of all o.a.s.request.*ResponseWriters with the extends notation that Ryan mentioned above. In addition, I'll throw in a log message (to satisfy Erik's concern) in the constructor of each of the deprecated classes stating that these classes are going away very soon, so please change references to o.a.s.response.* 2. adds the old o.a.s.request.*ResponseWriters to o.a.s.response.*ResponseWriters 3. merges with my existing patch which updates references everywhere else including solrconfig.xml. I think that should satisfy everyone. I'll throw up a patch hopefully by the end of the week. Cheers, Chris 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 Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config 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] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797123#action_12797123 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/6/10 2:48 PM: - Hi All: In the interest of moving forward on this, I'll go with option B, as I think I've made my point (as have others) and this is something important to get wrapped up IMO. I'd like to have an understanding though that in the next release of SOLR (1.6?) the deprecated classes can go away. Or, as Uri and Patrick pointed out, if the release cycle picks up then at worst 1.7. Thanks to everyone for their thoughtful comments. I am going to throw up a new patch that: 1. replaces the content of all o.a.s.request.\*ResponseWriters with the extends notation that Ryan mentioned above. In addition, I'll throw in a log message (to satisfy Erik's concern) in the constructor of each of the deprecated classes stating that these classes are going away very soon, so please change references to o.a.s.response.\* 2. adds the old o.a.s.request.\*ResponseWriters to o.a.s.response.\*ResponseWriters 3. merges with my existing patch which updates references everywhere else including solrconfig.xml. I think that should satisfy everyone. I'll throw up a patch hopefully by the end of the week. Cheers, Chris was (Author: chrismattmann): Hi All: In the interest of moving forward on this, I'll go with option B, as I think I've made my point (as have others) and this is something important to get wrapped up IMO. I'd like to have an understanding though that in the next release of SOLR (1.6?) the deprecated classes can go away. Or, as Uri and Patrick pointed out, if the release cycle picks up then at worst 1.7. Thanks to everyone for their thoughtful comments. I am going to throw up a new patch that: 1. replaces the content of all o.a.s.request.*ResponseWriters with the extends notation that Ryan mentioned above. In addition, I'll throw in a log message (to satisfy Erik's concern) in the constructor of each of the deprecated classes stating that these classes are going away very soon, so please change references to o.a.s.response.* 2. adds the old o.a.s.request.*ResponseWriters to o.a.s.response.*ResponseWriters 3. merges with my existing patch which updates references everywhere else including solrconfig.xml. I think that should satisfy everyone. I'll throw up a patch hopefully by the end of the week. Cheers, Chris 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 Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config 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-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797244#action_12797244 ] Chris A. Mattmann commented on SOLR-1602: - Hey Ryan: +1 on the SVN move to handle the package creation/class movement/deprecation classes. However, you'll still want to apply the existing patch I threw up (step 3 above on my prior comment) that updates the refs everywhere in the code/contrib and config to use the new pkg name. +1 on waiting the few days, thanks for your help and for offering to commit the solution. Cheers, Chris 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 Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config 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-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12796185#action_12796185 ] Chris A. Mattmann commented on SOLR-1602: - bq. I bet 99% of the users do not care about a wrongly named package when everything works. But they care when things stop working. Code organization is secondary to usability. Let us not cause discomfort to our users for such a trivial issue. I wouldn't be so quick to bet what 99% of your users think without some solid evidence to back that up. And no, code organization is not second to usability to all parties -- it depends on what hat you're using. To you it may be, but not to everyone. bq. End users do not dictate code level organization but they do have an influence when compatibility is involved. In this case, it is an inconvenience for many of them which can be avoided easily, so why not? Because satisfying end-users is only looking at one of the stakeholders of the system and ignoring the others. bq. I agree with Hoss. This is too much discussion over too small an issue. I think things are quite clear. Hoss, Erik, Noble and I all feel that breaking compatibility is not worth it. So lets do what needs to be done and get on with more important things. The issue is far from clear as far as I'm concerned and I'm the one who reported the issue. The comments on this issue from others are evidence of that. The issue will be satisfied when there is clear consensus from the parties involved. 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 Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config 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-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795871#action_12795871 ] Chris A. Mattmann commented on SOLR-1602: - Hi Erik, I'm sorry that you feel that way. I had one committer (Ryan) who voted on the related thread I posted on this ( http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200912.mbox/%3cc760cb08.8b0a%25chris.a.mattm...@jpl.nasa.gov%3e ) and agreed with the issue as I've proposed even (with no deprecations). In terms of speaking for your user community that's a pretty lofty statement assuming that the view of 2 committers is that of your user community. This hasn't been my Apache experience, nor my experience developing software in general. BTW, besides being a developer, I'm also one of SOLR's _users_ as well (as I'm sure you are too), so we're really wearing two hats here. I may be a different type of user than the one you're targeting, but I'm a user nonetheless and that should speak for something. As for the Lucene index example, in terms of going to extreme, that's an extreme example, right? We're not talking about a data file format here. We're talking about a package move of classes that are really in the wrong package, of which there are about 10 of those classes in use right now (and by in use, we're really talking about configuration because there's not that many people that are compiling against them I would venture to guess, and if they are, I stand firm it's better to be verbose in those situations). That's a big difference in terms of indexes that can grow big, and that need to be long lived and maintained than a solrconfig.xml file. As far as a log message in the deprecated classes, that's an interesting case. I'm assuming that this would catch users of SOLR that upgraded to 1.5 but that didn't upgrade their solrconfig.xml, right (assuming that class deprecations go in)? The only problem I see with that is that Joe user isn't always savvy enough to go into a log file and if he is, then he's likely already savvy enough to have read CHANGES.txt, right? Like I said above, we could provide a script along with this patch (attached to this issue) that users are required to run to upgrade their solrconfig.xml files when upgrading to 1.5. This is pretty much what a lot of other Apache projects, e.g., Hadoop, HBase do, in the form of telling users that they need to run DFS upgrade on any Hadoop upgrade as a matter of principle, see: http://hadoop.apache.org/common/docs/r0.17.2/hdfs_user_guide.html#Upgrade+and+Rollback. Cheers, Chris 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 Assignee: Noble Paul 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] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795871#action_12795871 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 5:24 PM: - Hi Erik, I'm sorry that you feel that way. I had one committer (Ryan) who voted on the related thread I posted on this ( http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200912.mbox/%3cc760cb08.8b0a%25chris.a.mattm...@jpl.nasa.gov%3e ) and agreed with the issue as I've proposed even (with no deprecations). In terms of speaking for your user community that's a pretty lofty statement assuming that the view of 2 committers is that of your user community. This hasn't been my Apache experience, nor my experience developing software in general. BTW, besides being a developer, I'm also one of SOLR's _users_ as well (as I'm sure you are too), so we're really wearing two hats here. I may be a different type of user than the one you're targeting, but I'm a user nonetheless and that should speak for something. As for the Lucene index example, in terms of going to extreme, that's an extreme example, right? We're not talking about a data file format here. We're talking about a package move of classes that are really in the wrong package, of which there are about 10 of those classes in use right now (and by in use, we're really talking about configuration because there's not that many people that are compiling against them I would venture to guess, and if they are, I stand firm it's better to be verbose in those situations). That's a big difference in terms of indexes that can grow big, and that need to be long lived and maintained than a solrconfig.xml file. As far as a log message in the deprecated classes, that's an interesting case. I'm assuming that this would catch users of SOLR that upgraded to 1.5 but that didn't upgrade their solrconfig.xml, right (assuming that class deprecations go in)? The only problem I see with that is that Joe user isn't always savvy enough to go into a log file and if he is, then he's likely already savvy enough to have read CHANGES.txt, right? In other words, why wait until runtime to catch something that could have been caught apriori? Like I said above, we could provide a script along with this patch (attached to this issue) that users are required to run to upgrade their solrconfig.xml files when upgrading to 1.5. This is pretty much what a lot of other Apache projects, e.g., Hadoop, HBase do, in the form of telling users that they need to run DFS upgrade on any Hadoop upgrade as a matter of principle, see: http://hadoop.apache.org/common/docs/r0.17.2/hdfs_user_guide.html#Upgrade+and+Rollback. Cheers, Chris was (Author: chrismattmann): Hi Erik, I'm sorry that you feel that way. I had one committer (Ryan) who voted on the related thread I posted on this ( http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200912.mbox/%3cc760cb08.8b0a%25chris.a.mattm...@jpl.nasa.gov%3e ) and agreed with the issue as I've proposed even (with no deprecations). In terms of speaking for your user community that's a pretty lofty statement assuming that the view of 2 committers is that of your user community. This hasn't been my Apache experience, nor my experience developing software in general. BTW, besides being a developer, I'm also one of SOLR's _users_ as well (as I'm sure you are too), so we're really wearing two hats here. I may be a different type of user than the one you're targeting, but I'm a user nonetheless and that should speak for something. As for the Lucene index example, in terms of going to extreme, that's an extreme example, right? We're not talking about a data file format here. We're talking about a package move of classes that are really in the wrong package, of which there are about 10 of those classes in use right now (and by in use, we're really talking about configuration because there's not that many people that are compiling against them I would venture to guess, and if they are, I stand firm it's better to be verbose in those situations). That's a big difference in terms of indexes that can grow big, and that need to be long lived and maintained than a solrconfig.xml file. As far as a log message in the deprecated classes, that's an interesting case. I'm assuming that this would catch users of SOLR that upgraded to 1.5 but that didn't upgrade their solrconfig.xml, right (assuming that class deprecations go in)? The only problem I see with that is that Joe user isn't always savvy enough to go into a log file and if he is, then he's likely already savvy enough to have read CHANGES.txt, right? Like I said above, we could provide a script along with this patch (attached to this issue) that users are required to run to upgrade their solrconfig.xml files when upgrading to 1.5. This is pretty
[jira] Updated: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1602: Attachment: upgrade_solr_config - the SOLR config upgrade script I mentioned. 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 Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config 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-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795896#action_12795896 ] Chris A. Mattmann commented on SOLR-1602: - bq. my question is .WHY? to change a few files from one package to another? The user may not even care if the entire all classes are put into one package . My question is since when are design decisions for a software system dictated by the end users of your application? In other words, the two concerns are orthogonal. At NASA, I don't consult end users of the software I develop regarding the organization of the software's code structure. End-user concerns are mostly with functional properties (performability, scalability, etc...) with a few NFP's sprinkled in (extensibility, ease of use, configurability, etc.), and not design decisions. However, that doesn't mean that design decisions (or improvements) shouldn't be made. Modern distributed software has many stakeholders, including end-users, software developers, architects, managers, etc. This is clearly addressing a concern of a few of those stakeholders (architects, developers [you could argue either end of this], managers [who may market the software and where clean organization is something they'd like to add as a selling point], but end-users are not really one of them in this case I'll agree). 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 Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt, SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config 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] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795896#action_12795896 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 7:05 PM: - bq. my question is .WHY? to change a few files from one package to another? The user may not even care if the entire all classes are put into one package . My question is since when are design decisions for a software system dictated by the end users of your application? In other words, the two concerns are orthogonal. At NASA, I don't consult end users of the software I develop regarding the organization of the software's code structure. End-user concerns are mostly with functional properties (performability, scalability, etc...) with a few NFP's sprinkled in (extensibility, ease of use, configurability, etc.), and not design decisions. However, that doesn't mean that design decisions (or improvements) shouldn't be made. Modern distributed software has many stakeholders, including end-users, software developers, architects, managers, etc. This is clearly addressing a concern of a few of those stakeholders (architects, developers [you could argue either end of this], managers [who may market the software and where clean organization is something they'd like to add as a selling point], but end-users are not really one of them in this case I'll agree). Ultimately because of this, the goal is to reap the benefits of good design and code organization within acceptable bounds to the user. That's really the discussion point at hand. I believe acceptable bounds to be: # Remove the classes from the package structure right now to deal with this move swiftly and reduce confusion (where are there 2 copies of the same class, in different packages?) Admittedly, this is an architect/developer/manager issue more so than an end-user one. # Provide a simple, 1 line upgrade script that end-users can upgrade their solrconfig.xml file with. That way when and if they employ the approach you mentioned Noble (i.e., copying their old configuration), there is minute additional effort to upgrade the config. I've done the deprecation route on one of my projects at NASA 7-8 years ago in a highly similar situation. In fact, it was way more extreme. We moved most of our core Java classes (100s of them) from a top-level package to another top-level package. In doing so, we kept replicas of the Java classes in the old package structure using the extends structure with deprecations as shown by Ryan above. We saw 0 measurable benefit of doing this, and we had 100s-1000s of end users of the software across many NASA centers and external organizations. And to me, it was just an organizational mess that caused confusion among new developers we hired to evolve the code. So, I just don't see the benefit. From a code management point of view it added extra work to the developer/architect/manager stakeholders more than anything else. Cheers, Chris was (Author: chrismattmann): bq. my question is .WHY? to change a few files from one package to another? The user may not even care if the entire all classes are put into one package . My question is since when are design decisions for a software system dictated by the end users of your application? In other words, the two concerns are orthogonal. At NASA, I don't consult end users of the software I develop regarding the organization of the software's code structure. End-user concerns are mostly with functional properties (performability, scalability, etc...) with a few NFP's sprinkled in (extensibility, ease of use, configurability, etc.), and not design decisions. However, that doesn't mean that design decisions (or improvements) shouldn't be made. Modern distributed software has many stakeholders, including end-users, software developers, architects, managers, etc. This is clearly addressing a concern of a few of those stakeholders (architects, developers [you could argue either end of this], managers [who may market the software and where clean organization is something they'd like to add as a selling point], but end-users are not really one of them in this case I'll agree). 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 Assignee: Noble Paul Fix For: 1.5 Attachments: SOLR-1602.Mattmann.112509.patch.txt,
[jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795896#action_12795896 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 7:15 PM: - bq. my question is .WHY? to change a few files from one package to another? The user may not even care if the entire all classes are put into one package . My question is since when are code-level and architecture-level design decisions for a software system directly dictated by the end users of your application? At NASA, I don't consult end users of the software I develop regarding the organization of the software's code structure. End-user concerns are mostly with functional properties (performability, scalability, etc...) with a few NFP's sprinkled in (extensibility, ease of use, configurability, etc.), and not design decisions. While it is true that these concerns have a great impact on the software system's architecture, the notion of code-level organization is a bit orthogonal. However, that doesn't mean that design decisions (or improvements) shouldn't be made. Modern distributed software has many stakeholders, including end-users, software developers, architects, managers, etc. This is clearly addressing a concern of a few of those stakeholders (architects, developers [you could argue either end of this], managers [who may market the software and where clean organization is something they'd like to add as a selling point], but end-users are not really one of them in this case I'll agree). Ultimately because of this, the goal is to reap the benefits of good design and code organization within acceptable bounds to the user. That's really the discussion point at hand. I believe acceptable bounds to be: # Remove the classes from the package structure right now to deal with this move swiftly and reduce confusion (where are there 2 copies of the same class, in different packages?) Admittedly, this is an architect/developer/manager issue more so than an end-user one. # Provide a simple, 1 line upgrade script that end-users can upgrade their solrconfig.xml file with. That way when and if they employ the approach you mentioned Noble (i.e., copying their old configuration), there is minute additional effort to upgrade the config. I've done the deprecation route on one of my projects at NASA 7-8 years ago in a highly similar situation. In fact, it was way more extreme. We moved most of our core Java classes (100s of them) from a top-level package to another top-level package. In doing so, we kept replicas of the Java classes in the old package structure using the extends structure with deprecations as shown by Ryan above. We saw 0 measurable benefit of doing this, and we had 100s-1000s of end users of the software across many NASA centers and external organizations. And to me, it was just an organizational mess that caused confusion among new developers we hired to evolve the code. So, I just don't see the benefit. From a code management point of view it added extra work to the developer/architect/manager stakeholders more than anything else. Cheers, Chris was (Author: chrismattmann): bq. my question is .WHY? to change a few files from one package to another? The user may not even care if the entire all classes are put into one package . My question is since when are design decisions for a software system dictated by the end users of your application? In other words, the two concerns are orthogonal. At NASA, I don't consult end users of the software I develop regarding the organization of the software's code structure. End-user concerns are mostly with functional properties (performability, scalability, etc...) with a few NFP's sprinkled in (extensibility, ease of use, configurability, etc.), and not design decisions. However, that doesn't mean that design decisions (or improvements) shouldn't be made. Modern distributed software has many stakeholders, including end-users, software developers, architects, managers, etc. This is clearly addressing a concern of a few of those stakeholders (architects, developers [you could argue either end of this], managers [who may market the software and where clean organization is something they'd like to add as a selling point], but end-users are not really one of them in this case I'll agree). Ultimately because of this, the goal is to reap the benefits of good design and code organization within acceptable bounds to the user. That's really the discussion point at hand. I believe acceptable bounds to be: # Remove the classes from the package structure right now to deal with this move swiftly and reduce confusion (where are there 2 copies of the same class, in different packages?) Admittedly, this is an architect/developer/manager issue more so than an end-user one. # Provide a simple, 1 line upgrade
[jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795896#action_12795896 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/3/10 4:47 AM: - bq. my question is .WHY? to change a few files from one package to another? The user may not even care if the entire all classes are put into one package . My question is since when are code-level and architecture-level design decisions for a software system directly dictated by the end users of your application? At NASA, I don't consult end users of the software I develop regarding the organization of the software's code structure. End-user concerns are mostly with functional properties (performability, scalability, etc...) with a few NFP's sprinkled in (extensibility, ease of use, configurability, etc.), and not design decisions. While it is true that these concerns have a great impact on the software system's architecture, the notion of code-level organization is a bit orthogonal. However, that doesn't mean that design decisions (or improvements) shouldn't be made. Modern distributed software has many stakeholders, including end-users, software developers, architects, managers, etc. This is clearly addressing a concern of a few of those stakeholders (architects, developers [you could argue either end of this], managers [who may market the software and where clean organization is something they'd like to add as a selling point], but end-users are not really one of them in this case I'll agree). Ultimately because of this, the goal is to reap the benefits of good design and code organization within acceptable bounds to the user. That's really the discussion point at hand. I believe acceptable bounds to be: # Remove the classes from the package structure right now to deal with this move swiftly and reduce confusion (i.e., why are there 2 copies of the same class, in different packages?) Admittedly, this is an architect/developer/manager issue more so than an end-user one. # Provide a simple, 1 line upgrade script that end-users can upgrade their solrconfig.xml file with. That way when and if they employ the approach you mentioned Noble (i.e., copying their old configuration), there is minute additional effort to upgrade the config. I've done the deprecation route on one of my projects at NASA 7-8 years ago in a highly similar situation. In fact, it was way more extreme. We moved most of our core Java classes (100s of them) from a top-level package to another top-level package. In doing so, we kept replicas of the Java classes in the old package structure using the extends structure with deprecations as shown by Ryan above. We saw 0 measurable benefit of doing this, and we had 100s-1000s of end users of the software across many NASA centers and external organizations. And to me, it was just an organizational mess that caused confusion among new developers we hired to evolve the code. So, I just don't see the benefit. From a code management point of view it added extra work to the developer/architect/manager stakeholders more than anything else. Cheers, Chris was (Author: chrismattmann): bq. my question is .WHY? to change a few files from one package to another? The user may not even care if the entire all classes are put into one package . My question is since when are code-level and architecture-level design decisions for a software system directly dictated by the end users of your application? At NASA, I don't consult end users of the software I develop regarding the organization of the software's code structure. End-user concerns are mostly with functional properties (performability, scalability, etc...) with a few NFP's sprinkled in (extensibility, ease of use, configurability, etc.), and not design decisions. While it is true that these concerns have a great impact on the software system's architecture, the notion of code-level organization is a bit orthogonal. However, that doesn't mean that design decisions (or improvements) shouldn't be made. Modern distributed software has many stakeholders, including end-users, software developers, architects, managers, etc. This is clearly addressing a concern of a few of those stakeholders (architects, developers [you could argue either end of this], managers [who may market the software and where clean organization is something they'd like to add as a selling point], but end-users are not really one of them in this case I'll agree). Ultimately because of this, the goal is to reap the benefits of good design and code organization within acceptable bounds to the user. That's really the discussion point at hand. I believe acceptable bounds to be: # Remove the classes from the package structure right now to deal with this move swiftly and reduce confusion (where are there 2 copies of the same
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795776#action_12795776
]
Chris A. Mattmann commented on SOLR-1602:
-
bq. I've got no strong opinions about moving the code (it would probably be
easier to understand if we changed it, but so many people use IDEs these days
that i odn't know if it matters) but if we do change it i'd prefer to go the
deprecation route just out of consistency with how we've dealt with the
RequestHandlers and other utilities classes in the past - it's relatively
trivial to do, so there's very little down side - and while it's true someone
w/ deprecation warnings turned off probably won't notice - that's kind of the
point behind doing deprecations, you get them if you want, you ignore them if
you don't - but things don't break.
Thanks for the comments Hoss. As for deprecations I'm totally for them, when
the intention is to limit the impact on classes and code that has infected a
code base and the sheer impact of changing all of the package imports etc. is
so burndensome that you want to give someone some time to do it, while still
moving forward with the refactoring. I don't think that's the case here.
ResponseWriters aren't extensible as we've went back and forth all the time
about. I doubt many people have extended them. As far as writing their own, the
code is likely in their own package structure. So, I think in this case,
despite being different than what you guys have done before (which is a con),
the pro is the change is so minute and likely of little impact, we want the
compiler to throw an error or 2, so the user can fix those one or 2 and be set
for all future releases.
{quote}additionally: the config file issue should not be downplayed. yes it
would be a trivial search/replace, but that's precisely the reason why it would
aggravate users: because it would be such a trivial change w/o any obvious
benefit to the users.
(novice developers tend to be much more forgiving of eccentricities in the code
base then novice users are of upgrade incompatibilities)
{quote}
I'm just not seeing this. I'm a user of plenty of software and a developer of
the same. If someone told me I'd have to do a find/replace on a config file to
take advantage of a new version of software, and that find replace would have
the impact of 7 or 8 lines which I probably haven't touched in the config file
anyways I really wouldn't care (in other words the benefits far outweigh the
negatives). Though this is a generalization, I'd say on average, customers for
software I've developed over the last 10 years really haven't either.
If it makes you feel better I could strip out and upload a small patch that
only changes the sorlconfig.xml file part of this issue, and then in
CHANGES.txt we could reference this issue and tell the users, OK here's a quick
way to upgrade an existing deployment:
patch -p0 curl
https://issues.apache.org/jira/secure/attachment/12426188/SOLR-1602.configonly.patch.txt;
or something like that?
Oh, also I opened up a vote thread for this. If you get a chance could you vote
on it? Thanks a lot Hoss.
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
Assignee: Noble Paul
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] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795831#action_12795831 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 6:17 AM: - Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you as a development team are willing to accommodate these types of users, even though it's _highly_ encouraged. - user B is the type that believes it makes sense to read CHANGES.txt first. (clap clap) - let's take the example of user A: in this case, the guy goes to run a query and ask for a response with wt=veolcity and some selected template. The query breaks, with a SOLR error, with an informative message to the likes of: response writer o.a.solr.request.VelocityResponseWriter doesn't exist. I'm annoyed, but I say, hmm why would this not work anymore. Let me take a look to see what response writers are present on the classpath with a jar tvf (if I'm not savvy enough to do this then we've got a whole other problem on our hands). Even if this approach doesn't pan out, I'd argue user A is still savvy enough at that point to, _read_the_instruction_manual. In doing so, he finds the answer to his question. It's reactive rather than proactive, but we still arrive at a solution with a small amount of acceptable effort. (BTW in this case, user A is annoyed for what he believes to be no good reason, but I can tell you from experience in government, research/academia and industry, this happens all the time. As developers, and good designers there is a good reason [better organization for a small user A annoyance cost]). - let's take the example of user B. It's a trivial subcase of user A's scenario, to the point where the user reads CHANGES.txt, notes the information in there, and proactively updates a few lines of XML in his configuration file So, anyways, I hope I've made my point and I don't really ever seem to get a lot of support on these types of issues, regardless. As a software architect and someone that teaches a graduate course in this stuff, I can tell you putting things titled ResponseWriter in a request package is not the way to go, regardless if SOLR has made 20 releases so far or 1 (software architecture recovery, static analysis, and a host of other issues are affected by this. Imagine in 10 years a company has a SOLR deployment long after SOLR ++ or some-other-search-service +++ 2.0 has come out. Someone has to come in and recover the architecture of a SOLR system so that they can understand how the changes they'd like to make to evolve the system will impact the so-called load bearing walls. These types of issues, if caught early on, help reduce this effort and ultimately reduce cost.) Cheers, Chris was (Author: chrismattmann): Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've got to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you as a development team are willing to accommodate these types of users, even
[jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795831#action_12795831 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 6:18 AM: - Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you as a development team are willing to accommodate these types of users, even though it's _highly_ encouraged that they read CHANGES.txt on any upgrades or when they download the software. - user B is the type that believes it makes sense to read CHANGES.txt first. (clap clap) - let's take the example of user A: in this case, the guy goes to run a query and ask for a response with wt=veolcity and some selected template. The query breaks, with a SOLR error, with an informative message to the likes of: response writer o.a.solr.request.VelocityResponseWriter doesn't exist. I'm annoyed, but I say, hmm why would this not work anymore. Let me take a look to see what response writers are present on the classpath with a jar tvf (if I'm not savvy enough to do this then we've got a whole other problem on our hands). Even if this approach doesn't pan out, I'd argue user A is still savvy enough at that point to, _read_the_instruction_manua_l. In doing so, he finds the answer to his question. It's reactive rather than proactive, but we still arrive at a solution with a small amount of acceptable effort. (BTW in this case, user A is annoyed for what he believes to be no good reason, but I can tell you from experience in government, research/academia and industry, this happens all the time. As developers, and good designers there is a good reason [better organization for a small user A annoyance cost]). - let's take the example of user B. It's a trivial subcase of user A's scenario, to the point where the user reads CHANGES.txt, notes the information in there, and proactively updates a few lines of XML in his configuration file So, anyways, I hope I've made my point and I don't really ever seem to get a lot of support on these types of issues, regardless. As a software architect and someone that teaches a graduate course in this stuff, I can tell you putting things titled ResponseWriter in a request package is not the way to go, regardless if SOLR has made 20 releases so far or 1 (software architecture recovery, static analysis, and a host of other issues are affected by this. Imagine in 10 years a company has a SOLR deployment long after SOLR ++ or some-other-search-service +++ 2.0 has come out. Someone has to come in and recover the architecture of a SOLR system so that they can understand how the changes they'd like to make to evolve the system will impact the so-called load bearing walls. These types of issues, if caught early on, help reduce this effort and ultimately reduce cost.) Cheers, Chris was (Author: chrismattmann): Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you
[jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795831#action_12795831 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 6:19 AM: - Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you as a development team are willing to accommodate these types of users, even though it's _highly_ encouraged that they read CHANGES.txt on any upgrades or when they download the software. - user B is the type that believes it makes sense to read CHANGES.txt first. (clap clap) - let's take the example of user A: in this case, the guy goes to run a query and ask for a response with wt=veolcity and some selected template. The query breaks, with a SOLR error, with an informative message to the likes of: response writer o.a.solr.request.VelocityResponseWriter doesn't exist. I'm annoyed, but I say, hmm why would this not work anymore. Let me take a look to see what response writers are present on the classpath with a jar tvf (if I'm not savvy enough to do this then we've got a whole other problem on our hands). Even if this approach doesn't pan out, I'd argue user A is still savvy enough at that point to, _read_the_instruction_manual_. In doing so, he finds the answer to his question. It's reactive rather than proactive, but we still arrive at a solution with a small amount of acceptable effort. (BTW in this case, user A is annoyed for what he believes to be no good reason, but I can tell you from experience in government, research/academia and industry, this happens all the time. As developers, and good designers there is a good reason [better organization for a small user A annoyance cost]). - let's take the example of user B. It's a trivial subcase of user A's scenario, to the point where the user reads CHANGES.txt, notes the information in there, and proactively updates a few lines of XML in his configuration file So, anyways, I hope I've made my point and I don't really ever seem to get a lot of support on these types of issues, regardless. As a software architect and someone that teaches a graduate course in this stuff, I can tell you putting things titled ResponseWriter in a request package is not the way to go, regardless if SOLR has made 20 releases so far or 1 (software architecture recovery, static analysis, and a host of other issues are affected by this. Imagine in 10 years a company has a SOLR deployment long after SOLR ++ or some-other-search-service +++ 2.0 has come out. Someone has to come in and recover the architecture of a SOLR system so that they can understand how the changes they'd like to make to evolve the system will impact the so-called load bearing walls. These types of issues, if caught early on, help reduce this effort and ultimately reduce cost.) Cheers, Chris was (Author: chrismattmann): Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you
[jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795831#action_12795831 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 6:17 AM: - Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you as a development team are willing to accommodate these types of users, even though it's _highly_ encouraged that they read CHANGES.txt on any upgrades or when they download the software. - user B is the type that believes it makes sense to read CHANGES.txt first. (clap clap) - let's take the example of user A: in this case, the guy goes to run a query and ask for a response with wt=veolcity and some selected template. The query breaks, with a SOLR error, with an informative message to the likes of: response writer o.a.solr.request.VelocityResponseWriter doesn't exist. I'm annoyed, but I say, hmm why would this not work anymore. Let me take a look to see what response writers are present on the classpath with a jar tvf (if I'm not savvy enough to do this then we've got a whole other problem on our hands). Even if this approach doesn't pan out, I'd argue user A is still savvy enough at that point to, _read_the_instruction_manual. In doing so, he finds the answer to his question. It's reactive rather than proactive, but we still arrive at a solution with a small amount of acceptable effort. (BTW in this case, user A is annoyed for what he believes to be no good reason, but I can tell you from experience in government, research/academia and industry, this happens all the time. As developers, and good designers there is a good reason [better organization for a small user A annoyance cost]). - let's take the example of user B. It's a trivial subcase of user A's scenario, to the point where the user reads CHANGES.txt, notes the information in there, and proactively updates a few lines of XML in his configuration file So, anyways, I hope I've made my point and I don't really ever seem to get a lot of support on these types of issues, regardless. As a software architect and someone that teaches a graduate course in this stuff, I can tell you putting things titled ResponseWriter in a request package is not the way to go, regardless if SOLR has made 20 releases so far or 1 (software architecture recovery, static analysis, and a host of other issues are affected by this. Imagine in 10 years a company has a SOLR deployment long after SOLR ++ or some-other-search-service +++ 2.0 has come out. Someone has to come in and recover the architecture of a SOLR system so that they can understand how the changes they'd like to make to evolve the system will impact the so-called load bearing walls. These types of issues, if caught early on, help reduce this effort and ultimately reduce cost.) Cheers, Chris was (Author: chrismattmann): Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you
[jira] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795831#action_12795831 ] Chris A. Mattmann edited comment on SOLR-1602 at 1/2/10 6:21 AM: - Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit to my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but you as a development team are willing to accommodate these types of users, even though it's _highly_ encouraged that they read CHANGES.txt on any upgrades or when they download the software. - user B is the type that believes it makes sense to read CHANGES.txt first. (clap clap) - let's take the example of user A: in this case, the guy goes to run a query and ask for a response with wt=veolcity and some selected template. The query breaks, with a SOLR error, with an informative message to the likes of: response writer o.a.solr.request.VelocityResponseWriter doesn't exist. I'm annoyed, but I say, hmm why would this not work anymore. Let me take a look to see what response writers are present on the classpath with a jar tvf (if I'm not savvy enough to do this then we've got a whole other problem on our hands). Even if this approach doesn't pan out, I'd argue user A is still savvy enough at that point to, _read_the_instruction_manual_. In doing so, he finds the answer to his question. It's reactive rather than proactive, but we still arrive at a solution with a small amount of acceptable effort. (BTW in this case, user A is annoyed for what he believes to be no good reason, but I can tell you from experience in government, research/academia and industry, this happens all the time. As developers, and good designers there is a good reason [better organization for a small user A annoyance cost]). - let's take the example of user B. It's a trivial subcase of user A's scenario, to the point where the user reads CHANGES.txt, notes the information in there, and proactively updates a few lines of XML in his configuration file So, anyways, I hope I've made my point and I don't really ever seem to get a lot of support on these types of issues, regardless. As a software architect and someone that teaches a graduate course in this stuff, I can tell you putting things titled ResponseWriter in a request package is not the way to go, regardless if SOLR has made 20 releases so far or 1 (software architecture recovery, static analysis, and a host of other issues are affected by this. Imagine in 10 years a company has a SOLR deployment long after SOLR ++ or some-other-search-service +++ 2.0 has come out. Someone has to come in and recover the architecture of a SOLR system so that they can understand how the changes they'd like to make to evolve the system will impact the so-called load bearing walls. These types of issues, if caught early on, help reduce this effort and ultimately reduce cost.) Cheers, Chris was (Author: chrismattmann): Hi Erik, Thanks for your feedback. My comments below: bq. Your rationalization only makes sense for developers that are compiling things... consider the case where someone has enabled the Velocity response writer (since it isn't yet enabled by default) and then it gets moved. Their upgrade is going to break for no good reason. I'm sorry but I guess I feel it's more important to be strict and informative, rather than loose and accommodating on these types of changes. Let's elucidate a real scenario. 1. I'm a SOLR 1.4 user. 2. I'm using the Velocity Response Writer, which means, I've gone to the trouble of making a small edit my solrconfig.xml configuration, and added a queryResponseWriter by enabling it with a few lines of XML in my configuration. 3. I decide I'm going to use SOLR 1.5. (corollary) SOLR-1602 goes in as I've proposed, with no deprecations 4. I upgrade to SOLR 1.5. - user A is the type that doesn't bother reading CHANGES.txt. Ideally this isn't the user you want to design for, but
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795834#action_12795834 ] Chris A. Mattmann commented on SOLR-1602: - Furthermore, to add one small corollary to my last point: the reason I'm pushing so strongly for no deprecations is that I'd like to kill 2 birds with one stone: address those such as user A or B above (only configuration updates), as well as addressing those users who are compiling and building a SOLR upgrade too. Anyhoo, Happy New Years, everyone! I'll be back around tomorrow. 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 Assignee: Noble Paul 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] Issue Comment Edited: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795346#action_12795346 ] Chris A. Mattmann edited comment on SOLR-1602 at 12/30/09 4:34 PM: --- Hi Ryan: Thanks. bq. Sounds fine... except for the back compatibility issues - especially for people upgrading with the same solrconfig.xml There are 8 response writers defined by default in solrconfig.xml. That doesn't seem too unwieldy a job for find/replace as far as configuration upgrades for someone moving from SOLR x.y to SOLR 1.5. As for code, yes, unfortunately users will have to recompile their response writers and update a few package names/imports per response writer which they'd probably want/have to do anyways on an upgrade regardless. bq. When we moved all the handlers to a new package o.a.solr.handler, it left a bunch of deprecated calsses in o.a.solr.request. You could certainly do this, and I've done it before in other projects. The tradeoff is, what type of message from the Java compiler do you want to notify you as a consumer of the SOLR java classes: # A deprecation (that could easily get swallowed if someone compiles with deprecation notifications off) # A compiler error, forcing the user to perform the small amount of legwork to update package refs I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in this case since most of the ReponseWriters aren't friendly to user extension or sub-classing. bq. Also, if we make a 'response' package, seems SolrQueryResponse.java should go there. Agreed, the patch I attached should move it there. was (Author: chrismattmann): Hi Ryan: Thanks. bq. Sounds fine... except for the back compatibility issues - especially for people upgrading with the same solrconfig.xml There are 8 response writers defined by default in solrconfig.xml. That doesn't seem too unwieldy a job for find/replace as far as configuration upgrades for someone moving from SOLR x.y to SOLR 1.5. As for code, yes, unfortunately users will have to recompile their response writers and update a few package names/imports per response writer which they'd probably want/have to do anyways on an upgrade regardless. bq. When we moved all the handlers to a new package o.a.solr.handler, it left a bunch of deprecated calsses in o.a.solr.request. You could certainly do this, and I've done it before in other projects. The tradeoff is, what type of message from the Java compiler do you want to notify you as a consumer of the SOLR java classes: # A deprecation (that could easily get swallowed if someone compiles with deprecation notifications off # A compiler error, forcing the user to perform the small amount of legwork to update package refs I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in this case since most of the ReponseWriters aren't friendly to user extension or sub-classing. bq. Also, if we make a 'response' package, seems SolrQueryResponse.java should go there. Agreed, the patch I attached should move it there. 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-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795346#action_12795346 ] Chris A. Mattmann commented on SOLR-1602: - Hi Ryan: Thanks. bq. Sounds fine... except for the back compatibility issues - especially for people upgrading with the same solrconfig.xml There are 8 response writers defined by default in solrconfig.xml. That doesn't seem too unwieldy a job for find/replace as far as configuration upgrades for someone moving from SOLR x.y to SOLR 1.5. As for code, yes, unfortunately users will have to recompile their response writers and update a few package names/imports per response writer which they'd probably want/have to do anyways on an upgrade regardless. bq. When we moved all the handlers to a new package o.a.solr.handler, it left a bunch of deprecated calsses in o.a.solr.request. You could certainly do this, and I've done it before in other projects. The tradeoff is, what type of message from the Java compiler do you want to notify you as a consumer of the SOLR java classes: # A deprecation (that could easily get swallowed if someone compiles with deprecation notifications off # A compiler error, forcing the user to perform the small amount of legwork to update package refs I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in this case since most of the ReponseWriters aren't friendly to user extension or sub-classing. bq. Also, if we make a 'response' package, seems SolrQueryResponse.java should go there. Agreed, the patch I attached should move it there. 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-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795355#action_12795355 ] Chris A. Mattmann commented on SOLR-1602: - Hi Ryan: bq. but since this is a breaking change - that would need explicitly called out in CHANGES.txt, we should get pretty wide consensus before moving forward... +1, I'll call a vote. Cheers, Chris 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-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795373#action_12795373 ] Chris A. Mattmann commented on SOLR-1602: - Hi Noble, bq. the patch does not apply. iis it not updated to trunk? Not sure, what message you getting? I'll take a look. I posted it originally in November so it's entirely possible it's out of date. Cheers, Chris 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-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795431#action_12795431 ] Chris A. Mattmann commented on SOLR-1602: - Hey Ryan, You are exactly right. When I created the patch in Eclipse, it negated to do the add +++ part of the patch b/c it saw the files as getting moved. Note that's why the patch doesn't apply -- it tries to make changes to the response writer class packages based on the path org/apache/solr/response/WriterName.java, which doesn't exist yet. To apply this patch: 1. first move the response writers into a new folder (response). Also copy SolrQueryResponse there. 2. apply the patch Cheers, Chris 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 Assignee: Noble Paul 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-1688) Inner class FieldCacheSources should be refactored into their own classes
[
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
outside class, present in
[jira] Issue Comment Edited: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes
[
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794688#action_12794688 ] Chris A. Mattmann commented on SOLR-1688: - bq. Chris, isn't referring to it as a ValueSource instance enough for SOLR-1586? Unfortunately, no. Grant's last patch for SOLR-1586 created a StrFieldSource, which isn't visible outside of its class. bq. That is not really a problem. The field types are always loaded by Solr so whether they are an inner class or independent does not matter too much. It's not a problem as much as it is inconsistent. Some FieldCacheSources are defined inline in their associated FieldType class, some are defined outside of it, for no rhyme or reason. This patch makes them all consistently defined in their own separate class, making it easier for extension, use and inheritance. 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.
[jira] Commented: (SOLR-1689) Make LongConstValueSource and TrieDateFieldSource classes public
[ https://issues.apache.org/jira/browse/SOLR-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794691#action_12794691 ] Chris A. Mattmann commented on SOLR-1689: - Hi Dušan: I put up a patch on SOLR-1688 that addresses your issue as part of this. Cheers, Chris Make LongConstValueSource and TrieDateFieldSource classes public Key: SOLR-1689 URL: https://issues.apache.org/jira/browse/SOLR-1689 Project: Solr Issue Type: Wish Components: search Reporter: Dušan Omerčević Priority: Minor In our custom request handler, we are boosting the query by decreasing recency of a document (thus implementing time bias). Solr provides BoostedQuery and ReciprocalFloatFunction classes that we use to implement time bias. But there are two classes, LongConstValueSource in org.apache.solr.search.ValueSourceParser, and TrieDateFieldSource in org.apache.solr.schema.TrieField, which are helpful in time bias implementation but which are defined as private. Currently, we have made our own copies of these two classes. I wish you would make these two classes public in order for us to reuse them in our implementation of time bias functionality. I'm sure this would be beneficial to others, too. Thank you. -- 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
[
https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794693#action_12794693
]
Chris A. Mattmann commented on SOLR-1586:
-
Hi Grant:
bq. What's the bug here?
Your last patch referenced StrFieldSource in the GeoHashField class we
developed:
{code}
+ @Override
+ public ValueSource getValueSource(SchemaField field, QParser parser) {
+return new StrFieldSource(field.name);
+ }
+
{code}
Of course, StrFieldSource is a private class defined in StrField in the
o.a.solr.schema package. This led me to take a look at realize that the
FieldSources are really defined inconsistently (check out SOLR-1688, patch
available).
Cheers,
Chris
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:
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] Issue Comment Edited: (SOLR-1586) Create Spatial Point FieldTypes
[
https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794693#action_12794693
]
Chris A. Mattmann edited comment on SOLR-1586 at 12/27/09 4:31 PM:
---
Hi Grant:
bq. What's the bug here?
Your last patch referenced StrFieldSource in the GeoHashField class we
developed:
{code}
+ @Override
+ public ValueSource getValueSource(SchemaField field, QParser parser) {
+return new StrFieldSource(field.name);
+ }
+
{code}
Of course, StrFieldSource is a private class defined in StrField in the
o.a.solr.schema package. This led me to take a look and realize that the
FieldSources are really defined inconsistently (check out SOLR-1688, patch
available).
Cheers,
Chris
was (Author: chrismattmann):
Hi Grant:
bq. What's the bug here?
Your last patch referenced StrFieldSource in the GeoHashField class we
developed:
{code}
+ @Override
+ public ValueSource getValueSource(SchemaField field, QParser parser) {
+return new StrFieldSource(field.name);
+ }
+
{code}
Of course, StrFieldSource is a private class defined in StrField in the
o.a.solr.schema package. This led me to take a look at realize that the
FieldSources are really defined inconsistently (check out SOLR-1688, patch
available).
Cheers,
Chris
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:
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
[ https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794699#action_12794699 ] Chris A. Mattmann commented on SOLR-1586: - bq. No it's not. It's package private. Is there something that isn't working? Interesting. Eclipse was giving me an error on using StrFieldSource in GeoHashField, right on that line I pasted above. It said StrFieldSource not found, and so taking a look it looked like StrFieldSource was an inner class (hard to see that little } at the end and whether it was defined inside of StrField or not). So I thought you were referencing an inner (private) class from StrField external to it. Funny now though after an Eclipse rebuild, Eclispe seems to be OK with StrFieldSource and its referencing in GeoHashField (which it should since they are both in the same package). Regardless though, this illustrates my point on SOLR-1688 -- these FieldCacheSources should be defined a bit more consistently -- when looking at a bunch of code, it's hard to see whether it was an inner class or a separate class defined in the same java file. 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: 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-1688) Inner class FieldCacheSources should be refactored into their own classes
[ https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794722#action_12794722 ] Chris A. Mattmann commented on SOLR-1688: - Hi Yonik: It wasn't a huge deal for me regarding public or private for the FieldCacheSources. I had some weird Eclipse error that pointed out that StrFieldSource was a class defined inside of another java file (originally I thought it was an inner class, but later found out it wasn't) as part of SOLR-1586. That led me to looking at this issue, and like I said the troubling part isn't that it's an inner class, versus an outer class (although outer classes are certainly cleaner for anything that will be used outside of the package). The troubling part is that some of these classes, e.g., DoubleFieldSource, FloatFieldSource, are defined as outer, public classes in an entirely different package (o.a.solr.search.function), whereas some of them (e.g., StrFieldSource, SortableDoubleFieldSource) are defined as outer classes inside of their FieldType constituents. That's inconsistent. Furthermore, the base class, FieldCacheSource, and ultimately its parent, ValueSource, are both intrinsically tied to the o.a.solr.search.function package, and are both public outer classes defined in their own java file(s). This is also inconsistent. The patch I attached associates all FieldCacheSources in the o.a.solr.search.function package (where the rest of them are defined and where their parents are also defined) and IMO fixes up these inconsistencies. Cheers, Chris 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.
[jira] Commented: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes
[
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794729#action_12794729
]
Chris A. Mattmann commented on SOLR-1688:
-
{quote}
But at this point... why mess with it? consistency?
{quote}
Yes, consistency. And the fact that applying this patch doesn't break anything,
it just cleans it up. With respect to why mess with it, I guess my question
is: why not?
Furthermore, like I said above, the placement of ValueSource and
FieldCacheSource in the o.a.solr.search.function package suggests that these
classes and their children likely belong in that package rather than
o.a.solr.schema, or furthermore that some refactoring is necessary. This is an
initial step towards that refactoring.
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.
[jira] Commented: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes
[
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794737#action_12794737
]
Chris A. Mattmann commented on SOLR-1688:
-
{quote}
I'm against making all ValueSource classes public. Some of them will clearly be
implementations very specific to a FieldType, and those implementation details
shouldn't be exposed unless needed.
{quote}
I don't get this especially when you yourself said most of these classes don't
really have detailed implementations (which I can corroborate when I put the
patch together for this issue looking at the code). Also, there is at least one
other community request to do this, SOLR-1689, albeit for a few select
ValueSources.
{quote}
No, the implementation of FieldType.getValueSource() is up to that FieldType
and it can make perfect sense to be co-located (esp if it's an implementation
detail of the FieldType).
{quote}
Then why isn't ValueSource and FieldCacheSource in the o.a.solr.schema package?
And more so, why is it OK for some and not OK for others, especially when none
of the ValueSource implementation classes is greater than a few hundred lines
of code, if that?
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.
[jira] Commented: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes
[
https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794748#action_12794748
]
Chris A. Mattmann commented on SOLR-1688:
-
{quote}
Rhetorical question: should all implementations of Map be in the java.util
package?
{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}
Think of it this way - some FieldType's may implement their getValueSource with
a publicly defined ValueSource and others may not.
{quote}
This makes sense so long as there is a reason. 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? I'm
not sure I see one, which is why I created this issue. And let's be clear.
Consistency, code style, maintainability _are_ important issues and following a
pattern in one situation while not following it in another (similar or same)
situation is not a great example of style or consistency.
{quote}It's not the case that for a given FooFieldType that there should be a
publicly usable FooValueSource. There should never be any guarantee that a
specific FieldType use a specific implementation of a ValueSource. The only
guarantee should be that it work. {quote}
The patch I put up still allows everything to work and doesn't change this
requirement.
{quote}
And if that's the case, one should ask why all these value sources should be
public?
{quote}
Because it's more consistent, and thus, more maintainable. 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? You
can argue that it doesn't take much time to make that determination, which I'll
give you, but I'll argue back it isn't consistent. If there's not a good reason
to make them all live in search.function or live inside of the FieldTypes in
schema, and it's really a case-by-case reason, then I'd like to hear some of
those case-by-cases.
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.
[jira] Created: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes
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 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.
[jira] Updated: (SOLR-1688) Inner class FieldCacheSources should be refactored into their own classes
[ https://issues.apache.org/jira/browse/SOLR-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1688: Attachment: SOLR-1688.Mattmann.122609.patch.txt 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.
[jira] Updated: (SOLR-1586) Create Spatial Point FieldTypes
[ https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1586: Attachment: SOLR-1586.Mattmann.122609.patch.txt - updated Grant's patch with more javadocs - formatting updates - fixed bug about referencing StrFieldSource via SOLR-1688 I get errors on the following tests: [junit] Tests run: 2, Failures: 1, Errors: 0, Time elapsed: 2.473 sec [junit] Test org.apache.solr.search.function.distance.DistanceFunctionTest FAILED [junit] Tests run: 5, Failures: 1, Errors: 0, Time elapsed: 6.32 sec [junit] Test org.apache.solr.schema.PolyFieldTest FAILED Which I think Grant noted in his prior comment. 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: 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
[ https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12794494#action_12794494 ] Chris A. Mattmann commented on SOLR-1586: - Grant: Thanks! +1 on the patch -- I think it's pretty much ready to go. Cheers, Chris 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-1669) Make XMLWriter write out xml that references the SOLR response XSD/DTD
[
https://issues.apache.org/jira/browse/SOLR-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793241#action_12793241
]
Chris A. Mattmann commented on SOLR-1669:
-
{quote}
Back compat.
XML Parsers can be configured to do validation if/when a schema/dtd is
declared. Clients unknowningly using a parser configured that way could (and
most likely would) perceive a big slow down in their apps if we started
including the schema declaration and that triggered expensive validation when
they didn't want it.
there are also people using the XML response format for incredibly small
responses (thing an autosuggest component) where a schema delcaration would
double the size of hte response
{quote}
Okey dokey -- no schema by default then!
I'll try and prepare an update to this issue and to SOLR-17 and throw up the
patches today. Thanks for the feedback!
Make XMLWriter write out xml that references the SOLR response XSD/DTD
---
Key: SOLR-1669
URL: https://issues.apache.org/jira/browse/SOLR-1669
Project: Solr
Issue Type: Improvement
Components: Response Writers
Affects Versions: 1.2, 1.3, 1.4
Environment: My MacBook Pro, Christmas-break style.
Reporter: Chris A. Mattmann
Fix For: 1.5
Attachments: SOLR-1669.Mattmann.121709.patch.txt
As described in SOLR-17, this is patch #2 of 3. It will make a simple
modification to XMLWriter which makes the output response XML reference the
SOLR XSD file. This way, clients can validate against 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-1669) Make XMLWriter write out xml that references the SOLR response XSD/DTD
[
https://issues.apache.org/jira/browse/SOLR-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12793246#action_12793246
]
Chris A. Mattmann commented on SOLR-1669:
-
Hey Hoss:
{quote}
1. that doesn't sound right ... i thought Schema declaration URIs were like
Namespace URIs - they were just a unique name, that the XML parser would then
be configured with a mapping to a local file (or remote URL) for the parser to
use? ... it's suppose to be a real URL?!?!?!
{quote}
Schema declaration URIs are like namespace URIs, however, you can provide a
schemaLocation that is a referenced URL, then the XML parser can decide (as one
of its strategies) to pull it down. I found this on the XML Schema standards
site at the W3C:
http://www.w3.org/TR/xmlschema-1/#schema-loc
Here's the relevant part pasted in:
{noformat}
Schema Representation Constraint: Schema Document Location Strategy
Given a namespace name (or none) and (optionally) a URI reference from
xsi:schemaLocation or xsi:noNamespaceSchemaLocation, schema-aware processors
may implement any combination of the following strategies, in any order:
1 Do nothing, for instance because a schema containing components for the given
namespace name is already known to be available, or because it is known in
advance that no efforts to locate schema documents will be successful (for
example in embedded systems);
2 Based on the location URI, identify an existing schema document, either as a
resource which is an XML document or a schema element information item, in
some local schema repository;
3 Based on the namespace name, identify an existing schema document, either as
a resource which is an XML document or a schema element information item, in
some local schema repository;
4 Attempt to resolve the location URI, to locate a resource on the web which is
or contains or references a schema element;
5 Attempt to resolve the namespace name to locate such a resource.
Whenever possible configuration and/or invocation options for selecting and/or
ordering the implemented strategies should be provided.
{noformat}
However, reading this standards doc though suggests something that we can do to
alleviate this. We can provide the XSD in the SOLR war file and then reference
it locally as you suggest (by setting xsi:schemaLocation to it).
{quote}
2. If schema URIs really are URLs then we should absolutely NOT reference
anything in *.apache.org for the schema URL ... we (and our users) don't
want/need every solr client on the planet hitting the apache webservers for
this kind of validation. it would make a lot more sense to include the XSD in
the war and keep it all on the same host
{quote}
Good point. I'll address as part of 1.
Make XMLWriter write out xml that references the SOLR response XSD/DTD
---
Key: SOLR-1669
URL: https://issues.apache.org/jira/browse/SOLR-1669
Project: Solr
Issue Type: Improvement
Components: Response Writers
Affects Versions: 1.2, 1.3, 1.4
Environment: My MacBook Pro, Christmas-break style.
Reporter: Chris A. Mattmann
Fix For: 1.5
Attachments: SOLR-1669.Mattmann.121709.patch.txt
As described in SOLR-17, this is patch #2 of 3. It will make a simple
modification to XMLWriter which makes the output response XML reference the
SOLR XSD file. This way, clients can validate against 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-17) XSD for solr requests/responses
[
https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792859#action_12792859
]
Chris A. Mattmann commented on SOLR-17:
---
Hi Noble:
{quote}
response does not contain a tag called responseHeader or an attribute called
status. so there is no type called responseHeader.
{quote}
You're right -- I think it's because the XSD is a bit old and the example
response XML from before has changed slightly. I'll bring the XSD/DTD up to
date.
See: https://issues.apache.org/jira/secure/attachment/12334355/solr-complex.xml
for an example of the old XML style.
Cheers,
Chris
XSD for solr requests/responses
---
Key: SOLR-17
URL: https://issues.apache.org/jira/browse/SOLR-17
Project: Solr
Issue Type: Improvement
Reporter: Mike Baranczak
Priority: Minor
Attachments: SOLR-17.Mattmann.121709.patch.txt, solr-complex.xml,
solr-rev2.xsd, solr.xsd, UselessRequestHandler.java
Attaching an XML schema definition for the responses and the update requests.
I needed to do this for myself anyway, so I might as well contribute it to
the project.
At the moment, I have no plans to write an XSD for the config documents, but
it wouldn't be a bad idea.
TODO: change the schema URL. I'm guessing that Apache already has some sort
of naming convention for these?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1669) Make XMLWriter write out xml that references the SOLR response XSD/DTD
[
https://issues.apache.org/jira/browse/SOLR-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792873#action_12792873
]
Chris A. Mattmann commented on SOLR-1669:
-
{quote}
do you mean to say that the schema location provided by the xml is a real url?
it is just a unique string . it could be just about anything else.
{quote}
Yes, I mean it's a real URL. Once the patch from SOLR-17 is applied, it will
become a real URL (and as part of SOLR-17 there needs to be a new site
build/push out).
{quote}
The default should be to not include a schema.
{quote}
Why?
Make XMLWriter write out xml that references the SOLR response XSD/DTD
---
Key: SOLR-1669
URL: https://issues.apache.org/jira/browse/SOLR-1669
Project: Solr
Issue Type: Improvement
Components: Response Writers
Affects Versions: 1.2, 1.3, 1.4
Environment: My MacBook Pro, Christmas-break style.
Reporter: Chris A. Mattmann
Fix For: 1.5
Attachments: SOLR-1669.Mattmann.121709.patch.txt
As described in SOLR-17, this is patch #2 of 3. It will make a simple
modification to XMLWriter which makes the output response XML reference the
SOLR XSD file. This way, clients can validate against 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-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792751#action_12792751
]
Chris A. Mattmann commented on SOLR-1131:
-
{quote}
Actually, we should probably move the creation of the actual PointType off to
SOLR-1586, anyway. The reason I want n-dimensional is b/c this stuff is useful
for more than just traditional lat/lon.
{quote}
+1, I was going to suggest the same thing. BTW, the geohash field type is ready
when you have a chance to take a look.
Cheers,
Chris
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
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
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792052#action_12792052 ] Chris A. Mattmann commented on SOLR-1131: - Hey Grant: Let me give this a quick review. Won't take longer than 20 mins. Thanks for pushing forward on this. Cheers, Chris 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: 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 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
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792055#action_12792055 ] Chris A. Mattmann commented on SOLR-1131: - +1. Looks good, Grant. Let's get this sucker committed... Thanks! Cheers, Chris 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: 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 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] Created: (SOLR-1669) Make XMLWriter write out xml that references the SOLR response XSD/DTD
Make XMLWriter write out xml that references the SOLR response XSD/DTD --- Key: SOLR-1669 URL: https://issues.apache.org/jira/browse/SOLR-1669 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.4, 1.3, 1.2 Environment: My MacBook Pro, Christmas-break style. Reporter: Chris A. Mattmann Fix For: 1.5 As described in SOLR-17, this is patch #2 of 3. It will make a simple modification to XMLWriter which makes the output response XML reference the SOLR XSD file. This way, clients can validate against it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1669) Make XMLWriter write out xml that references the SOLR response XSD/DTD
[ https://issues.apache.org/jira/browse/SOLR-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1669: Attachment: SOLR-1669.Mattmann.121709.patch.txt - patch to implement referencing of XSD by XMLWriter Make XMLWriter write out xml that references the SOLR response XSD/DTD --- Key: SOLR-1669 URL: https://issues.apache.org/jira/browse/SOLR-1669 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: My MacBook Pro, Christmas-break style. Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1669.Mattmann.121709.patch.txt As described in SOLR-17, this is patch #2 of 3. It will make a simple modification to XMLWriter which makes the output response XML reference the SOLR XSD file. This way, clients can validate against it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1646) Document the SOLR XML response schema in XMLSchema and DTD
[ https://issues.apache.org/jira/browse/SOLR-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann resolved SOLR-1646. - Resolution: Duplicate This issue is a duplicate of SOLR-17. Document the SOLR XML response schema in XMLSchema and DTD -- Key: SOLR-1646 URL: https://issues.apache.org/jira/browse/SOLR-1646 Project: Solr Issue Type: Improvement Components: clients - C#, clients - java, clients - php, clients - python, clients - ruby - flare, documentation, Response Writers, Schema and Analysis, search Affects Versions: 1.1.0, 1.2, 1.3, 1.4 Environment: My local Mac Book pro over Christmas Break. Reporter: Chris A. Mattmann Priority: Critical Fix For: 1.5 See this thread: http://www.lucidimagination.com/search/document/e8bb6cac84c1f520/namespaces_in_response_solr_1586#cc50ba9e9d8fe2dc For the background. The idea is to finally document the often alluded to (but never riefied) SOLR XML response schema/DTD. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1671) Unit tests to validate SOLR xml responses using XSD/DTD
Unit tests to validate SOLR xml responses using XSD/DTD --- Key: SOLR-1671 URL: https://issues.apache.org/jira/browse/SOLR-1671 Project: Solr Issue Type: Improvement Components: Response Writers Environment: My MacBook Pro. Reporter: Chris A. Mattmann Fix For: 1.5 According to SOLR-17, we should add some regression test cases (or perhaps modify the existing ones) for the XML response writer to ensure that any changes in its structure do not break the intended schema. This should help to contain people like Chris who keep trying to change 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-17) XSD for solr requests/responses
[ https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792357#action_12792357 ] Chris A. Mattmann commented on SOLR-17: --- Okay, patches attached (to this issue, and to SOLR-1669) and issues created (SOLR-1669 and SOLR-1671). I don't have one for SOLR-1671 yet, but could probably throw one together by next week. In the meanwhile, I think the patch for SOLR-17 and for SOLR-1669 are ready to go, so at least progress can be made there. Thanks! XSD for solr requests/responses --- Key: SOLR-17 URL: https://issues.apache.org/jira/browse/SOLR-17 Project: Solr Issue Type: Improvement Reporter: Mike Baranczak Priority: Minor Attachments: SOLR-17.Mattmann.121709.patch.txt, solr-complex.xml, solr-rev2.xsd, solr.xsd, UselessRequestHandler.java Attaching an XML schema definition for the responses and the update requests. I needed to do this for myself anyway, so I might as well contribute it to the project. At the moment, I have no plans to write an XSD for the config documents, but it wouldn't be a bad idea. TODO: change the schema URL. I'm guessing that Apache already has some sort of naming convention for these? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[ https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790787#action_12790787 ] Chris A. Mattmann commented on SOLR-17: --- In what way? And furthermore, I don't appreciate the tone of your comment. Is this the way you, as a committer, encourage people to contribute to SOLR? I hope not. XSD for solr requests/responses --- Key: SOLR-17 URL: https://issues.apache.org/jira/browse/SOLR-17 Project: Solr Issue Type: Improvement Reporter: Mike Baranczak Priority: Minor Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd, UselessRequestHandler.java Attaching an XML schema definition for the responses and the update requests. I needed to do this for myself anyway, so I might as well contribute it to the project. At the moment, I have no plans to write an XSD for the config documents, but it wouldn't be a bad idea. TODO: change the schema URL. I'm guessing that Apache already has some sort of naming convention for these? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[
https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790941#action_12790941
]
Chris A. Mattmann commented on SOLR-17:
---
{quote}
Chris, it seems that you are taking my comment personally. Please don't; it is
not my intention to ridicule anyone's efforts.
{quote}
I wouldn't say I took it personally -- as I said, I'm not sure I appreciated
the tone of the comment. A one-liner, that's curt, provides no background (lest
only an opinion), and that sounds like ridicule will elicit such a response in
many cases, see Netiquette Guidelines:
http://tools.ietf.org/html/rfc1855
{quote}
As you can see, this issue has been open for some time now and a major reason
is that we have never found a good use for an XSD. I'm merely trying to say
that it seems like we're trying to find use-cases for a solution instead of
starting with an actual need.
{quote}
Sure, judging by its issue number (17), I could tell it has been open for a
while. The ongoing conversation regarding SOLR-1586, see here:
http://www.lucidimagination.com/search/document/7094af4a3aa8bc03/namespaces_in_response_solr_1586
led me to this issue, as pointed out by Hoss. There _have_ been some relevant
discussions that have come up regarding XSD's, which was my point. So, I'm not
sure that we're _trying_ to find anything -- the discussion presented itself on
its own. Furthermore, even if the discussion hadn't occured, it doesn't seem
very contribution friendly to ignore something that clearly adds value to a
group of people. XML and XSD people exist and have their tools (as I noted
above, Doxygen, XMLSpy, etc.) for doing validation, and for generating sample
XML files, for designing XML, etc.. Just because there aren't a lot of votes on
the issue, or lots of mail traffic, it doesn't mean that the issue should not
get attention. I'm not sure what's so controversial about adding an XSD to the
SOLR trunk. Hence my point in calling attention to this issue. There's been a
patch available for quite some time. What's missing from the patch to get this
contribution into the trunk?
{quote}
My point is that Solr can use it we want to but Solr certainly does not need to
use it. I don't think we gain much by an XSD.
{quote}
I agree that SOLR, from a code/API/functionality perspective, does not _need_
to use it. However, it would not hurt anything to add the XSD as part of the
trunk for those that would like to download it and use it to understand how to
write additional SOLR XML consuming clients. Or for those that would like to
validate SOLR XML responses they receive. This isn't outside of the ordinary at
all, and I think only adds value, and doesn't take any away. If the concern is
maintaining it, I'd be happy to do so. I'm sure there are others that would
contribute as well.
XSD for solr requests/responses
---
Key: SOLR-17
URL: https://issues.apache.org/jira/browse/SOLR-17
Project: Solr
Issue Type: Improvement
Reporter: Mike Baranczak
Priority: Minor
Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd,
UselessRequestHandler.java
Attaching an XML schema definition for the responses and the update requests.
I needed to do this for myself anyway, so I might as well contribute it to
the project.
At the moment, I have no plans to write an XSD for the config documents, but
it wouldn't be a bad idea.
TODO: change the schema URL. I'm guessing that Apache already has some sort
of naming convention for these?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[
https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791042#action_12791042
]
Chris A. Mattmann commented on SOLR-17:
---
Hi Uri:
Thanks. Comments below:
{quote}
Having well defined XSD's for public services can be extremely helpful in many
aspects... together with proper version management they define the contract
between the users the the service. Some of the use cases that Chris listed
above are definitely valid and realistic. Moreover, XSD provides a natural and
proper documentation for the supported formats which any decent xml editor can
make use of and provide you with hints for writing the solrconfig.xml and the
schema.xml (for example).
{quote}
+1.
{quote}
That said... most of the xml formats in Solr are too generic to benefit from
XSD's. The only format where it makes sense is the schema.xml as it has an
expressive domain-driven structure. Unfortunately this is something you cannot
say for for the response formats and the solrconfig.xml where the
expressiveness lays within the values of the elements/attributes rather than in
the elements/attribute names themselves. XSD doesn't handle element/attribute
values very well.
{quote}
Kinda sorta. Regardless of how generic the XML used in SOLR is, I think it can
still benefit from being documented in an XSD. That way, as you mentioned
above, if it ever changes, with proper versioning, you have a baseline. In
addition, for those wanting to know what can and can't be done to be a valid
SOLR XML response (as I did w.r.t. geo stuff), the XSD/DTD can serve as a guide
regarding that interface. And beyond just names, there's cardinality that the
XSD could help validate (i.e., can you have sub-tags within a double in the
SOLR XML response? -- the answer is no, and this is something that could be
codified in a DTD/XSD). Furthermore, we could also document what each of the
valid attribute and element definitions are too, which would be useful even
from a documentation perspective.
Maybe the idea is that we should have XSD/DTDs for not only the services, but
also for some of the configuration. This is a completely valid idea and I'm +1
for it. However, as a start, I think contributing and committing the SOLR XML
response writer output XSD (and a DTD, which I'll attach) is something that
adds value, doesn't take anything away, or touch other parts of the code, etc.,
and is worthwhile to do.
Cheers,
Chris
XSD for solr requests/responses
---
Key: SOLR-17
URL: https://issues.apache.org/jira/browse/SOLR-17
Project: Solr
Issue Type: Improvement
Reporter: Mike Baranczak
Priority: Minor
Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd,
UselessRequestHandler.java
Attaching an XML schema definition for the responses and the update requests.
I needed to do this for myself anyway, so I might as well contribute it to
the project.
At the moment, I have no plans to write an XSD for the config documents, but
it wouldn't be a bad idea.
TODO: change the schema URL. I'm guessing that Apache already has some sort
of naming convention for these?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[
https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791146#action_12791146
]
Chris A. Mattmann commented on SOLR-17:
---
@Uri:
{quote}
Fair enough. I guess it can always serve as a reference to better understanding
what to expect from a Solr response (instead of trying to figure things out
from the code). Good thing about this generic format is that it's unlikely to
change that frequently, so the XSD's will probably not change that often as
well.
{quote}
+1, thanks for hearing me out!
@Hoss
{quote}
1. where should it live in source control? where should it live in the release
artifact?
2. what schema URI should we pick for identifying this? (i suspect apache.org
has a standard for this, so or at least precident from other projects, so we
should make sure we follow those examples before picking one arbitrarily
{quote}
In src, I think it should live here: src/xsd (let's call it solrresponse.xsd),
and let's make a DTD too (called solrresponse.dtd) that lives in src/dtd. In
release, let's make it live somewhere that gets published onto the SOLR website
(you guys are using forrest, right? I can put a patch together that copies it
to the right place). It would be great to have it at, say:
http://lucene.apache.org/solr/schema/solrresponse.xsd
http://lucene.apaceh.org/solr/dtd/solrresponse.dtd
In the long term, maybe we could version the URIs too, based on the current
SOLR version, but that's down the road.
{quote}
3. it won't do any good unless we make the XmlResponseWriter refrence the
schema URI so client tools can validate with it.
{quote}
Well it'll do some good just to have it out there. I'm a fan of incremental
patchiness, so as a start, can we make this issue just put the XSD/DTD into the
src, and then copy it to a Forrest accessible link, and then a do site rebuild?
Then, as patch #2, we tackle your #3 above. I agree, #3 is pretty trivial
(modifying a static final String in XMLWriter.java), but to me we can do it as
a separate, clean patch, not cluttered with adding the XSD/DTD and then
modifying Forrest (which this patch can do).
{quote}
4. we need hooks in our own test system for validating responses we get back to
catch potential bugs (either in the schema itself, or in xml that might get
inadvertantly changed)
{quote}
I think this is patch #3, or maybe #2a (and can go in along with #2 above), but
+1 for this too. I'm happy to contribute/lead the efforts here. I'll start
preparing patches right away.
Cheers,
Chris
XSD for solr requests/responses
---
Key: SOLR-17
URL: https://issues.apache.org/jira/browse/SOLR-17
Project: Solr
Issue Type: Improvement
Reporter: Mike Baranczak
Priority: Minor
Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd,
UselessRequestHandler.java
Attaching an XML schema definition for the responses and the update requests.
I needed to do this for myself anyway, so I might as well contribute it to
the project.
At the moment, I have no plans to write an XSD for the config documents, but
it wouldn't be a bad idea.
TODO: change the schema URL. I'm guessing that Apache already has some sort
of naming convention for these?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[ https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12790530#action_12790530 ] Chris A. Mattmann commented on SOLR-17: --- There are actually a lot of useful things that could be done with an XSD. For starters: # we could have validated the the XML i wanted to introduce as part of SOLR-1586 wouldn't work automatically. # we could generate a custom Solr XML Response Reader using JAXB # we could generate sample Solr XML Responses with ease using a tool like Doxygen or XMLSpy XSD for solr requests/responses --- Key: SOLR-17 URL: https://issues.apache.org/jira/browse/SOLR-17 Project: Solr Issue Type: Improvement Reporter: Mike Baranczak Priority: Minor Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd, UselessRequestHandler.java Attaching an XML schema definition for the responses and the update requests. I needed to do this for myself anyway, so I might as well contribute it to the project. At the moment, I have no plans to write an XSD for the config documents, but it wouldn't be a bad idea. TODO: change the schema URL. I'm guessing that Apache already has some sort of naming convention for these? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type
[
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789923#action_12789923
]
Chris A. Mattmann commented on SOLR-1123:
-
{quote}
I think the main issue with the inheritance right now is that the
QueryResponseWriter interface is dealing with a Writer rather than with an
OutputStream. This accounts for the hacky GenericBinaryResponseWriter.
{quote}
I'm taking a look at this.
{quote}
Looking at SOLR-1516 I'm a bit confused. I always had the impression that the
main idea behind the response writers is that all they need to know is how to
marshal a NamedList (so they don't need explicit knowledge of documents,
highlighting, etc...). But now the GenericTextResponseWriter knows about
documents (via the SingleResponseWriter). But perhaps I just go it wrong.
{quote}
Well if that's the main idea behind ResponseWriters as you put it, then as I
put it in SOLR-1516, it's pretty confusing. Users (who understand Lucene and
SOLR) know that if they query they get back o.a.lucene.Documents or
o.a.solr.SolrDocumentList, etc. The whole NamedList structure is pretty
confusing to me (and to others as I've noted on other issues and on the mailing
list). SOLR-1516 was an attempt to give those people writing ResponseWriters
(now) the ability to deal with results of queries, aka Documents (and not all
the other NamedList typeless bag of objects where you have to do instanceof
everwhere to unmarshall it). Clearly not all ResponseWriters will be able to
take advantage of this (e.g., those that need the specified output structures
provided by other components, e.g., Facets, etc.), which is why my original
patch called the two response writers I added Document*ResponseWriter b/c
that's what they dealt with.
Cheers,
Chris
Change the JSONResponseWriter content type
--
Key: SOLR-1123
URL: https://issues.apache.org/jira/browse/SOLR-1123
Project: Solr
Issue Type: Improvement
Reporter: Uri Boness
Fix For: 1.5
Attachments: JSON_contentType_incl_tests.patch
Currently the jSON content type is not used. Instead the palin/text content
type is used. The reason for this as I understand is to enable viewing the
json response as as text in the browser. While this is valid argument, I do
believe that there should at least be an option to configure this writer to
use the JSON content type. According to
[RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to
be application/json (and not text/x-json). The reason this can be very
helpful is that today you have plugins for browsers (e.g.
[JSONView|http://brh.numbera.com/software/jsonview]) that can render any page
with application/json content type in a user friendly manner (just like xml
is supported).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1652) Allow single unit test to be executed from SOLR build.xml
Allow single unit test to be executed from SOLR build.xml - Key: SOLR-1652 URL: https://issues.apache.org/jira/browse/SOLR-1652 Project: Solr Issue Type: New Feature Components: Build Affects Versions: 1.4, 1.3, 1.2 Environment: My local MacBook Reporter: Chris A. Mattmann Fix For: 1.5 While playing around and running someone's example code in the form of a test, I realized it might be nice to run a single test from the ant command line when testing SOLR. To my knowledge, there is no way to do this. So, I googled around and found a nice way of doing it. I'll contribute a patch that allows you to do: ant runtest -Dtest=fully qualified class name or just class name no package [-Dargs=jvm args for junit] which will run one of SOLR's unit tests at a time. You can also use *'s in the -Dtest= to run many test cases that match the * expression too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1652) Allow single unit test to be executed from SOLR build.xml
[ https://issues.apache.org/jira/browse/SOLR-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann resolved SOLR-1652. - Resolution: Won't Fix Thanks, Shalin. Since I didn't see documentation on this anywhere on the Solr Wiki, I went ahead and added a page: http://wiki.apache.org/solr/TestingSolr and a link to it on the Solr main page. Thanks! Allow single unit test to be executed from SOLR build.xml - Key: SOLR-1652 URL: https://issues.apache.org/jira/browse/SOLR-1652 Project: Solr Issue Type: New Feature Components: Build Affects Versions: 1.2, 1.3, 1.4 Environment: My local MacBook Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1652.Mattmann.121209.patch.txt While playing around and running someone's example code in the form of a test, I realized it might be nice to run a single test from the ant command line when testing SOLR. To my knowledge, there is no way to do this. So, I googled around and found a nice way of doing it. I'll contribute a patch that allows you to do: ant runtest -Dtest=fully qualified class name or just class name no package [-Dargs=jvm args for junit] which will run one of SOLR's unit tests at a time. You can also use *'s in the -Dtest= to run many test cases that match the * expression too. -- 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
[ https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1586: Attachment: SOLR-1586.Mattmann.121209.geohash.outarr.patch.txt Okay, so I gave up on outputting georss in the SOLRXmlResponse (*sniffle*). Instead, here's the 1st of 2 patches. This one outputs the point as a double array. I'm torn. It's probably more conceptually correct, but it's weirder from a I put in a string delimited by a whitespace and got out a point as an array. Nevertheless, I'm attaching it. Next one will just be a string. 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.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 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] Updated: (SOLR-1586) Create Spatial Point FieldTypes
[ https://issues.apache.org/jira/browse/SOLR-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1586: Attachment: SOLR-1586.Mattmann.121209.geohash.outstr.patch.txt , and #2, the string version. My +1 for this in the end. 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.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-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789833#action_12789833
]
Chris A. Mattmann commented on SOLR-1131:
-
Hi Grant:
Thanks. Your latest patch omits class-level javadoc I wrote for
DelegatingFieldType and for the #inform method in SchemaAware.
{code}
+/**
+ * An interface for {...@link FieldType}s that are poly fields, as defined in
a
+ * href=http://issues.apache.org/jira/browse/SOLR-1131;SOLR-1131/a, so that
+ * poly fields can declare the {...@link FieldType}s of their sub-fields.
+ *
+ * @since SOLR-1131
+ *
+ **/
+public interface DelegatingFieldType {
+
+ /**
+ *
+ * Returns the {...@link FieldType}s of the sub-fields for this poly-field.
+ *
+ * @return A {...@link List} of {...@link FieldType}s for the sub-fields of
a poly
+ * field.
+ */
+ public ListFieldType getSubTypes();
+}
{code}
{code}
+public interface SchemaAware {
+
+ /**
+ * Informs the {...@link IndexSchema} provided by the codeschema/code
+ * parameter of an event (e.g., a new {...@link FieldType} was added, etc.
+ *
+ * @param schema
+ * The {...@link IndexSchema} instance that inform of the update to.
+ *
+ * @since SOLR-1131
+ */
+ public void inform(IndexSchema schema);
+}
{code}
Other than that +1. Thanks for seeing this through to a great patch.
Cheers,
Chris
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: 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
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
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789330#action_12789330
]
Chris A. Mattmann commented on SOLR-1131:
-
Hi Grant:
bq.The array is sorted and array access is much faster and we often have to
loop over it to look it up.
OK, fair enough.
bq. I think comma makes sense.
OK, so you think it makes sense -- why? Because it's an N-dimensional array and
spaces are less user friendly as Yonik put it?
bq. As for the optimization stuff, I agree w/ Yonik, this is code that will be
called a lot.
I'm wondering what there is to agree with since optimization was never
defined. Are you talking speed? Are you talking memory efficiency? Code
readability? Maintainability? Some combination of all of those? There are
tradeoffs in everything. You could rewrite some of the provided java runtime
methods to squeeze out extra performance, but what's the point of libraries or
reusable functions then? The prior code that was in there basically rewrote
exactly what split() and trim() do, so why not reuse what's there? If you throw
up the performance flag, I would push back on readability and maintainability.
bq. It is logged, but for the poly fields, if the dyn field is already defined,
that's just fine.
Where is it logged? It wasn't in the most up-to-date patch, provided on
2009-12-10 04:34 PM. Here was the code snipped that was there:
{code}
+//For each poly field, go through and add the appropriate Dynamic field
+ for (FieldType fieldType : polyFieldTypes.values()) {
+if (fieldType instanceof DelegatingFieldType){
+ ListFieldType subs = ((DelegatingFieldType)
fieldType).getSubTypes();
+ if (subs.isEmpty() == false){
+//add a new dynamic field for each sub field type
+for (FieldType type : subs) {
+ log.debug(dynamic field creation for sub type: +
type.typeName);
+ SchemaField df = SchemaField.create(* +
FieldType.POLY_FIELD_SEPARATOR + type.typeName,
+ type, type.args);//TODO: is type.args right?
+ if (isDuplicateDynField(dFields, df) == false){
+addDynamicFieldNoDupCheck(dFields, df);
+ }
// NOTE: there is no else here, so I added an else and a log
message
+}
+ }
// NOTE: there is no else here, so I added an else and a log message
+}
+ }
+
{code}
Here's what I added:
{code}
+//For each poly field, go through and add the appropriate Dynamic field
+ for (FieldType fieldType : polyFieldTypes.values()) {
+if (fieldType instanceof DelegatingFieldType){
+ ListFieldType subs = ((DelegatingFieldType)
fieldType).getSubTypes();
+ if (!subs.isEmpty()){
+//add a new dynamic field for each sub field type
+for (FieldType type : subs) {
+ log.debug(dynamic field creation for sub type: +
type.typeName);
+ SchemaField df = SchemaField.create(* +
FieldType.POLY_FIELD_SEPARATOR + type.typeName,
+ type, type.args);//TODO: is type.args right?
+ if (!isDuplicateDynField(dFields, df)){
+addDynamicFieldNoDupCheck(dFields, df);
+ }
+ else{
+log.debug(dynamic field creation avoided: dynamic field:
[+df.getName()+] +
+ already defined in the schema!);
+ }
+
+}
+ }
+ else{
+log.debug(field type: [+fieldType.getTypeName()+]: no sub
fields defined);
+ }
+}
+ }
+
{code}
Also, I get that it's fine for the poly fields if the dyn field is already
defined (in fact, based on my mailing lists comments
http://old.nabble.com/SOLR-1131:-disconnect-between-fields-created-by-poly-fields-td26736431.html
I think this should _always_ be the case), but whether it's fine or not, it's
still worthy to log to provide someone more information.
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: SOLR-1131-IndexMultipleFields.patch,
SOLR-1131.Mattmann.121009.patch.txt, 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
[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789342#action_12789342 ] Chris A. Mattmann commented on SOLR-1131: - bq. Speed and memory. Unfortunately, it's at the cost of readability and maintainability. bq. As for logging, that code is all going away in the next patch, I think I'll take a look when you throw it up, thanks. Cheers, Chris 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: SOLR-1131-IndexMultipleFields.patch, SOLR-1131.Mattmann.121009.patch.txt, 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-1131) Allow a single field type to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789354#action_12789354 ] Chris A. Mattmann commented on SOLR-1131: - bq. Maybe. It took me all of 30 seconds to figure out what it was doing. I'll put some comments on it. While readability is important, Solr's goal is not to make a product that a CS101 grad can read, it's too build a blazing fast search server. That call could hit millions of times when indexing points. Sure, maybe the goal isn't for a CS101 grad to be able to easily understand the code, but SOLR's goal should include being open to ideas from the community that involve reusing standard Java library functions and not rewriting based on perception of speed and memory without empirical proof. Where's the evidence that using things like split and trim are so much more costly than rewriting those basic capabilities that they warrant not using them? 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: SOLR-1131-IndexMultipleFields.patch, SOLR-1131.Mattmann.121009.patch.txt, 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-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris A. Mattmann updated SOLR-1131:
Attachment: SOLR-1131.Mattmann.121109.patch.txt
OK, this is getting a lot closer to ready to commit.
Changes:
Hi All,
Updated patch:
{quote}
# Introduced a MultiValueSource - ValueSource that abstractly represents
ValueSources for poly fields, and other things.
{quote}
I added javadoc to this and the ASF license header.
{quote}
# Introduced PointValueSource - point(x,y,z) - a MultiValueSource that wraps
other value sources (could be called something else, I suppose)
{quote}
I put the ASF header before the package decl, to be consistent with the other
SOLR java files.
{quote}
# Add in SchemaAware callback mechanism so that Field Types and other schema
stuff can register dynamic fields, etc. after the schema has been created
{quote}
Added more javadoc here, and ASF license.
{quote}
# Incorporated various comments from Chris and Yonik.
{quote}
Thanks, I appreciate it. I'm still -1 on the way this patch deals with the
optimization issue. I'd like to see evidence that it makes sense to not use
split and trim.
Cheers,
Chris
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: 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
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] Issue Comment Edited: (SOLR-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789484#action_12789484
]
Chris A. Mattmann edited comment on SOLR-1131 at 12/11/09 7:39 PM:
---
Hi All,
Updated patch:
{quote}
# Introduced a MultiValueSource - ValueSource that abstractly represents
ValueSources for poly fields, and other things.
{quote}
I added javadoc to this and the ASF license header.
{quote}
# Introduced PointValueSource - point(x,y,z) - a MultiValueSource that wraps
other value sources (could be called something else, I suppose)
{quote}
I put the ASF header before the package decl, to be consistent with the other
SOLR java files.
{quote}
# Add in SchemaAware callback mechanism so that Field Types and other schema
stuff can register dynamic fields, etc. after the schema has been created
{quote}
Added more javadoc here, and ASF license.
{quote}
# Incorporated various comments from Chris and Yonik.
{quote}
Thanks, I appreciate it. I'm still -1 on the way this patch deals with the
optimization issue. I'd like to see evidence that it makes sense to not use
split and trim.
Cheers,
Chris
was (Author: chrismattmann):
OK, this is getting a lot closer to ready to commit.
Changes:
Hi All,
Updated patch:
{quote}
# Introduced a MultiValueSource - ValueSource that abstractly represents
ValueSources for poly fields, and other things.
{quote}
I added javadoc to this and the ASF license header.
{quote}
# Introduced PointValueSource - point(x,y,z) - a MultiValueSource that wraps
other value sources (could be called something else, I suppose)
{quote}
I put the ASF header before the package decl, to be consistent with the other
SOLR java files.
{quote}
# Add in SchemaAware callback mechanism so that Field Types and other schema
stuff can register dynamic fields, etc. after the schema has been created
{quote}
Added more javadoc here, and ASF license.
{quote}
# Incorporated various comments from Chris and Yonik.
{quote}
Thanks, I appreciate it. I'm still -1 on the way this patch deals with the
optimization issue. I'd like to see evidence that it makes sense to not use
split and trim.
Cheers,
Chris
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: 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
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
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789561#action_12789561
]
Chris A. Mattmann commented on SOLR-1131:
-
Hi Grant:
{quote}
My tests show it to be at least 7 times faster. But this should be obvious from
static analysis, too. First of all, String.split() uses a regex which then
makes a pass through the underlying character array. Then, trim has to go back
through and analyze the char array too, not to mention the extra String
creations. The optimized version here makes one pass and deals solely at the
char array level and only has to do the substring, which I think can be
optimized by the JVM to be a copy on write.
{quote}
Got it. A couple of points:
1. 7x faster is great, but could end up being noise if x = 2 ms. It matters if
x is say 2 minutes, agreed. If it's on the ms end then the expense of more
lines of (uncommented) code isn't worth it.
2. This code is likely to get called heavily on the indexing side, so
performance, though still an issue, is not as hugely important as say on the
searching side.
3. If you feel strongly about an optimized version of this magic splitAndTrim
function, how ability a utility function and refactor then? I would guess this
code could be used elsewhere, and that would help to satisfy my hunger for
reusability. I'll even javadoc the function and do the refactor if you'd like.
Cheers,
Chris
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: 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
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] Created: (SOLR-1646) Document the SOLR XML response schema in XMLSchema and DTD
Document the SOLR XML response schema in XMLSchema and DTD -- Key: SOLR-1646 URL: https://issues.apache.org/jira/browse/SOLR-1646 Project: Solr Issue Type: Improvement Components: clients - C#, clients - java, clients - php, clients - python, clients - ruby - flare, documentation, Response Writers, Schema and Analysis, search Affects Versions: 1.4, 1.3, 1.2, 1.1.0 Environment: My local Mac Book pro over Christmas Break. Reporter: Chris A. Mattmann Priority: Critical Fix For: 1.5 See this thread: http://www.lucidimagination.com/search/document/e8bb6cac84c1f520/namespaces_in_response_solr_1586#cc50ba9e9d8fe2dc For the background. The idea is to finally document the often alluded to (but never riefied) SOLR XML response schema/DTD. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1648) Rename XMLWriter (and XMLResponseWriter) to SolrXmlResponseWriter
Rename XMLWriter (and XMLResponseWriter) to SolrXmlResponseWriter - Key: SOLR-1648 URL: https://issues.apache.org/jira/browse/SOLR-1648 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.4, 1.3, 1.2 Environment: My local MacBook pro over the Christmas Break. Reporter: Chris A. Mattmann Fix For: 1.5 The current XMLWriter class is kind of a misnomer. It's not a generic XMLWriter by any means, and that's not its intention. Its intention is to write instances (as responses) of a particular XML schema that SOLR clients (written in Java, Python, pick-your-favorite-programming-language) that speak its XML protocol can understand. So, we should rename it to SolrXmlResponseWriter to indicate its unique XML speak. Morever, as part of the next issue I'm going to report (refactoring all ResponseWriters to be a bit more friendly), we should probably do away with the current XmlResponseWriter (which simply delegates to XmlWriter -- eeep) and just stick with SolrXmlResponseWriter. 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-1648) Rename XMLWriter (and XMLResponseWriter) to SolrXmlResponseWriter
[ https://issues.apache.org/jira/browse/SOLR-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789682#action_12789682 ] Chris A. Mattmann commented on SOLR-1648: - See this thread for more detail: http://www.lucidimagination.com/search/document/e8bb6cac84c1f520/namespaces_in_response_solr_1586#cc50ba9e9d8fe2dc Rename XMLWriter (and XMLResponseWriter) to SolrXmlResponseWriter - Key: SOLR-1648 URL: https://issues.apache.org/jira/browse/SOLR-1648 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.2, 1.3, 1.4 Environment: My local MacBook pro over the Christmas Break. Reporter: Chris A. Mattmann Fix For: 1.5 The current XMLWriter class is kind of a misnomer. It's not a generic XMLWriter by any means, and that's not its intention. Its intention is to write instances (as responses) of a particular XML schema that SOLR clients (written in Java, Python, pick-your-favorite-programming-language) that speak its XML protocol can understand. So, we should rename it to SolrXmlResponseWriter to indicate its unique XML speak. Morever, as part of the next issue I'm going to report (refactoring all ResponseWriters to be a bit more friendly), we should probably do away with the current XmlResponseWriter (which simply delegates to XmlWriter -- eeep) and just stick with SolrXmlResponseWriter. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1649) Refactor all ResponseWriters to be more extension-friendly
Refactor all ResponseWriters to be more extension-friendly -- Key: SOLR-1649 URL: https://issues.apache.org/jira/browse/SOLR-1649 Project: Solr Issue Type: Improvement Components: Response Writers Affects Versions: 1.4 Environment: My local MacBook pro over the Christmas break. Reporter: Chris A. Mattmann Fix For: 1.5 I'd like to refactor all the ResponseWriters to be a bit less brittle. ResponseWriters should follow a standard interface with more existing methods than is currently present in the interface, and with lots of refactored utility code and more concrete control/data flow. I'll take a hard look at the existing response writers and try to generalize. See this thread for background: http://www.lucidimagination.com/search/document/e8bb6cac84c1f520/namespaces_in_response_solr_1586#cc50ba9e9d8fe2dc -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1642) Change name of SOLR749Test
Change name of SOLR749Test -- Key: SOLR-1642 URL: https://issues.apache.org/jira/browse/SOLR-1642 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 1.4, 1.3 Environment: My local MacBook pro. Reporter: Chris A. Mattmann Fix For: 1.5 The test class named SOLR749Test is inconsistent with all of the rest of the unit tests, which aren't tied to their JIRA issue names. Some examples of best practices: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html http://blog.taragana.com/index.php/archive/java-unit-testing-best-practices/ http://junit.sourceforge.net/doc/faq/faq.htm#best -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1642) Change name of SOLR749Test
[ https://issues.apache.org/jira/browse/SOLR-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1642: Attachment: SOLR-1642.Mattmann.121009.patch.txt Change name of SOLR749Test -- Key: SOLR-1642 URL: https://issues.apache.org/jira/browse/SOLR-1642 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 1.3, 1.4 Environment: My local MacBook pro. Reporter: Chris A. Mattmann Fix For: 1.5 Attachments: SOLR-1642.Mattmann.121009.patch.txt The test class named SOLR749Test is inconsistent with all of the rest of the unit tests, which aren't tied to their JIRA issue names. Some examples of best practices: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html http://blog.taragana.com/index.php/archive/java-unit-testing-best-practices/ http://junit.sourceforge.net/doc/faq/faq.htm#best -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1642) Change name of SOLR749Test
[ https://issues.apache.org/jira/browse/SOLR-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris A. Mattmann updated SOLR-1642: Priority: Trivial (was: Major) Change name of SOLR749Test -- Key: SOLR-1642 URL: https://issues.apache.org/jira/browse/SOLR-1642 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 1.3, 1.4 Environment: My local MacBook pro. Reporter: Chris A. Mattmann Priority: Trivial Fix For: 1.5 Attachments: SOLR-1642.Mattmann.121009.patch.txt The test class named SOLR749Test is inconsistent with all of the rest of the unit tests, which aren't tied to their JIRA issue names. Some examples of best practices: http://googletesting.blogspot.com/2007/02/tott-naming-unit-tests-responsibly.html http://blog.taragana.com/index.php/archive/java-unit-testing-best-practices/ http://junit.sourceforge.net/doc/faq/faq.htm#best -- 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-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789003#action_12789003
]
Chris A. Mattmann edited comment on SOLR-1131 at 12/10/09 11:08 PM:
Hi All:
Here's a cut on the patch. Some questions/comments on the existing patch(es):
# Why use
{code}
private DynamicField[] dynamicFields;
{code}
instead of
{code}
ListDynamicField
{code}
or
{code}
CollectionDynamicField
{code}
in IndexSchema?
# There are a bunch of useless whitespace changes (e.g., in IndexSchema,
FieldType) in the existing patches. The final patch probably shouldn't include
those since it makes it difficult to understand what was actually changed.
# IndexSchema:
#* when checking for isDuplicateDynField, if it is, nothing is done. Shouldn't
this be where an exception is thrown or a message is logged? In the patch I'm
attaching I took the log approach.
# IndexSchema:
#* what happens if subs.isEmpty() == true?
#* maybe log message that says, dyn field definition is up to you?
#* I took the approach in my attached patch to log it.
# Why does getPolyFieldType(String) throw an exception if the field is not a
poly field type -- that seems a bit brittle? Also there's the NoEx version
anyways (why not just keep that one?). In the patch I've attached, I took the
approach of only including a getPolyFieldType that returns null rather than
throwing an ex (the NoEx version).
# CoordinateFieldType: why process 1 sub field types and then throw an
exception at the end? I cleaned this up to throw the Exception when it occurs.
# parsePoint in DistanceUtils, why use ',' as the separator -- use ' ' (at
least conforms to georss point then). I guess because you are supporting
N-dimensional points, right?
# parsePoint -- instead of complicated isolation loops, why not just use
trim()? I've taken that approach in the patch I've attached.
This patch passes all unit tests as well. This doesn't implement option C that
I proposed yet. Hopefully I'll get a chance to put that up later tonight.
was (Author: chrismattmann):
Hi All:
Here's a cut on the patch. Some questions/comments on the existing patch(es):
1. Why use
{code}
private DynamicField[] dynamicFields;
{code}
instead of
{code}
ListDynamicField
{code}
or
{code}
CollectionDynamicField
{code}
in IndexSchema?
2. There are a bunch of useless whitespace changes (e.g., in IndexSchema,
FieldType) in the existing patches. The final patch probably shouldn't include
those since it makes it difficult to understand what was actually changed.
3. IndexSchema:
- when checking for isDuplicateDynField, if it is, nothing is done.
Shouldn't this be where an exception is thrown or a message is logged? In the
patch I'm attaching I took the log approach.
4. IndexSchema:
- what happens if subs.isEmpty() == true?
- maybe log message that says, dyn field definition is up to you?
- I took the approach in my attached patch to log it.
5. Why does getPolyFieldType(String) throw an exception if the field is not a
poly field type -- that seems a bit brittle? Also there's the NoEx version
anyways (why not just keep that one?). In the patch I've attached, I took the
approach of only including a getPolyFieldType that returns null rather than
throwing an ex (the NoEx version).
6. CoordinateFieldType: why process 1 sub field types and then throw an
exception at the end? I cleaned this up to throw the Exception when it occurs.
7. parsePoint in DistanceUtils, why use ',' as the separator -- use ' ' (at
least conforms to georss point then). I guess because you are supporting
N-dimensional points, right?
8. parsePoint -- instead of complicated isolation loops, why not just use
trim()? I've taken that approach in the patch I've attached.
This patch passes all unit tests as well. This doesn't implement option C that
I proposed yet. Hopefully I'll get a chance to put that up later tonight.
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: SOLR-1131-IndexMultipleFields.patch,
SOLR-1131.Mattmann.121009.patch.txt, 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
[jira] Updated: (SOLR-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris A. Mattmann updated SOLR-1131:
Attachment: SOLR-1131.Mattmann.121009.patch.txt
Hi All:
Here's a cut on the patch. Some questions/comments on the existing patch(es):
1. Why use
{code}
private DynamicField[] dynamicFields;
{code}
instead of
{code}
ListDynamicField
{code}
or
{code}
CollectionDynamicField
{code}
in IndexSchema?
2. There are a bunch of useless whitespace changes (e.g., in IndexSchema,
FieldType) in the existing patches. The final patch probably shouldn't include
those since it makes it difficult to understand what was actually changed.
3. IndexSchema:
- when checking for isDuplicateDynField, if it is, nothing is done.
Shouldn't this be where an exception is thrown or a message is logged? In the
patch I'm attaching I took the log approach.
4. IndexSchema:
- what happens if subs.isEmpty() == true?
- maybe log message that says, dyn field definition is up to you?
- I took the approach in my attached patch to log it.
5. Why does getPolyFieldType(String) throw an exception if the field is not a
poly field type -- that seems a bit brittle? Also there's the NoEx version
anyways (why not just keep that one?). In the patch I've attached, I took the
approach of only including a getPolyFieldType that returns null rather than
throwing an ex (the NoEx version).
6. CoordinateFieldType: why process 1 sub field types and then throw an
exception at the end? I cleaned this up to throw the Exception when it occurs.
7. parsePoint in DistanceUtils, why use ',' as the separator -- use ' ' (at
least conforms to georss point then). I guess because you are supporting
N-dimensional points, right?
8. parsePoint -- instead of complicated isolation loops, why not just use
trim()? I've taken that approach in the patch I've attached.
This patch passes all unit tests as well. This doesn't implement option C that
I proposed yet. Hopefully I'll get a chance to put that up later tonight.
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: SOLR-1131-IndexMultipleFields.patch,
SOLR-1131.Mattmann.121009.patch.txt, 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] Issue Comment Edited: (SOLR-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789003#action_12789003
]
Chris A. Mattmann edited comment on SOLR-1131 at 12/10/09 11:08 PM:
Hi All:
Here's a cut on the patch. Some questions/comments on the existing patch(es):
# Why use
{code}
private DynamicField[] dynamicFields;
{code} instead of
{code}
ListDynamicField
{code} or
{code}
CollectionDynamicField
{code} in IndexSchema?
# There are a bunch of useless whitespace changes (e.g., in IndexSchema,
FieldType) in the existing patches. The final patch probably shouldn't include
those since it makes it difficult to understand what was actually changed.
# IndexSchema:
#* when checking for isDuplicateDynField, if it is, nothing is done. Shouldn't
this be where an exception is thrown or a message is logged? In the patch I'm
attaching I took the log approach.
# IndexSchema:
#* what happens if subs.isEmpty() == true?
#* maybe log message that says, dyn field definition is up to you?
#* I took the approach in my attached patch to log it.
# Why does getPolyFieldType(String) throw an exception if the field is not a
poly field type -- that seems a bit brittle? Also there's the NoEx version
anyways (why not just keep that one?). In the patch I've attached, I took the
approach of only including a getPolyFieldType that returns null rather than
throwing an ex (the NoEx version).
# CoordinateFieldType: why process 1 sub field types and then throw an
exception at the end? I cleaned this up to throw the Exception when it occurs.
# parsePoint in DistanceUtils, why use ',' as the separator -- use ' ' (at
least conforms to georss point then). I guess because you are supporting
N-dimensional points, right?
# parsePoint -- instead of complicated isolation loops, why not just use
trim()? I've taken that approach in the patch I've attached.
This patch passes all unit tests as well. This doesn't implement option C that
I proposed yet. Hopefully I'll get a chance to put that up later tonight.
was (Author: chrismattmann):
Hi All:
Here's a cut on the patch. Some questions/comments on the existing patch(es):
# Why use
{code}
private DynamicField[] dynamicFields;
{code}
instead of
{code}
ListDynamicField
{code}
or
{code}
CollectionDynamicField
{code}
in IndexSchema?
# There are a bunch of useless whitespace changes (e.g., in IndexSchema,
FieldType) in the existing patches. The final patch probably shouldn't include
those since it makes it difficult to understand what was actually changed.
# IndexSchema:
#* when checking for isDuplicateDynField, if it is, nothing is done. Shouldn't
this be where an exception is thrown or a message is logged? In the patch I'm
attaching I took the log approach.
# IndexSchema:
#* what happens if subs.isEmpty() == true?
#* maybe log message that says, dyn field definition is up to you?
#* I took the approach in my attached patch to log it.
# Why does getPolyFieldType(String) throw an exception if the field is not a
poly field type -- that seems a bit brittle? Also there's the NoEx version
anyways (why not just keep that one?). In the patch I've attached, I took the
approach of only including a getPolyFieldType that returns null rather than
throwing an ex (the NoEx version).
# CoordinateFieldType: why process 1 sub field types and then throw an
exception at the end? I cleaned this up to throw the Exception when it occurs.
# parsePoint in DistanceUtils, why use ',' as the separator -- use ' ' (at
least conforms to georss point then). I guess because you are supporting
N-dimensional points, right?
# parsePoint -- instead of complicated isolation loops, why not just use
trim()? I've taken that approach in the patch I've attached.
This patch passes all unit tests as well. This doesn't implement option C that
I proposed yet. Hopefully I'll get a chance to put that up later tonight.
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: SOLR-1131-IndexMultipleFields.patch,
SOLR-1131.Mattmann.121009.patch.txt, 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
[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789106#action_12789106
]
Chris A. Mattmann commented on SOLR-1131:
-
{quote}
A comma is more user friendly - spaces are often already used as delimiters in
quite a few places.
Why did you replace more optimized code that was already written in parsePoint
with less optimized code?
{quote}
Meh, I could go either way on the comma/space issue. It would be nice to be
compatible with an existing GeoPoint standard. I know georss uses space as the
delimeter -- do you know of any that use ,?
RE: optimized code, can you be explicit? I would argue the code I inserted is
more optimized from a readiability standpoint. It's a bit easier for your
typical CS101 grad to understand. All that was being done in the prior patch is
a set of forwards/backwards isolation loops to determine the start/end index to
substring out, in case you have:
34.333 ,100.1 OR
34.333,100.1 OR
34.333, 100.1
At first blush, trying to understand that code was a bit harder than simply
tokenizing on the known delimeter, and then trimming each tokenized value.
{code}
out = externalVal.split(,);
+ if(out.length != dimension){
+throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
incompatible dimension ( + dimension +
+) and values ( + externalVal + ). Only + i + values
specified);
+ }
+ for(int j=0; j out.length; j++){
+out[j] = out[j].trim();
+ }
{code}
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: SOLR-1131-IndexMultipleFields.patch,
SOLR-1131.Mattmann.121009.patch.txt, 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-1131) Allow a single field type to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12788116#action_12788116 ] Chris A. Mattmann commented on SOLR-1131: - Hi Yonik: I agree in general with your points above regarding unit tests. However, there seems to be a contradiction in your last statement to what you proposed above: bq. schema.xml: geo will be core... let's not add a new/different schema file in tests for this and simply add it to the latest schema12 Why have unit tests point at the actual schema? That explicitly ties your unit tests to the shipped ops schema, and then encourages people to write unit tests against it (which could lead to the specific number checks that will break when the schema is updated as you mentioned). Instead +1 for having a separate test schema even if it causes duplication it insulates change. Cheers, Chris 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: SOLR-1131-IndexMultipleFields.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.
