[jira] Updated: (SOLR-1297) Enable sorting by Function Query
[ https://issues.apache.org/jira/browse/SOLR-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-1297: -- Attachment: SOLR-1297.patch First crack at a patch. I think it's in pretty good shape, but I had to rewrite QueryParsing.parseSort(), so it bears some extra scrutiny (although I put tests in place first). Added a bunch of new tests for both parsing and for search (see QueryParsingTest and SortByFunctionTest). All existing and new tests pass. Enable sorting by Function Query Key: SOLR-1297 URL: https://issues.apache.org/jira/browse/SOLR-1297 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: SOLR-1297.patch It would be nice if one could sort by FunctionQuery. See also SOLR-773, where this was first mentioned by Yonik as part of the generic solution to geo-search -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789743#action_12789743 ] Grant Ingersoll commented on SOLR-773: -- Just an update: # SOLR-1131: aka poly fields is almost ready to go. Please review. # SOLR-1297: sort by function query just needs review and then can be committed. After that, we can add in the Cartesian Tier indexing and the Cartesian Tier QParserPlugin (after a little re-write). Then we need pseudo-fields and we likely want to hook in a per request function cache (maybe) Incorporate Local Lucene/Solr - Key: SOLR-773 URL: https://issues.apache.org/jira/browse/SOLR-773 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, lucene.tar.gz, screenshot-1.jpg, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, SOLR-773.patch, solrGeoQuery.tar, spatial-solr.tar.gz Local Lucene has been donated to the Lucene project. It has some Solr components, but we should evaluate how best to incorporate it into Solr. See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1650) Consider being able to cache function results per request
Consider being able to cache function results per request - Key: SOLR-1650 URL: https://issues.apache.org/jira/browse/SOLR-1650 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 1.5 Once we can sort, filter and boost by functions, it may be the case that the same function is executed for the same value over and over again. Consider ways to cache this information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1644) Provide a clean way to keep flags and helper objects in ResponseBuilder
[ https://issues.apache.org/jira/browse/SOLR-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789745#action_12789745 ] Yonik Seeley commented on SOLR-1644: While we should make it easy for custom components to store their own flags + state, etc, we should be careful about hiding the state of well known components. It's OK to hide internal implementation stuff, but we should leave anything useful to other components exposed (and more explicitly spell out what it means, if it can be changed by another component, etc). Whether a request is a faceting request or not could certainly be useful to other components... and as a bonus it eliminates a hash lookup for each component each time through the loop. Provide a clean way to keep flags and helper objects in ResponseBuilder --- Key: SOLR-1644 URL: https://issues.apache.org/jira/browse/SOLR-1644 Project: Solr Issue Type: Improvement Components: search Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 1.5 Attachments: SOLR-1644.patch Many components such as StatsComponent, FacetComponent etc keep flags and helper objects in ResponseBuilder. Having to modify the ResponseBuilder for such things is a very kludgy solution. Let us provide a clean way for components to keep arbitrary objects for the duration of a (distributed) search request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[
https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789759#action_12789759
]
Yonik Seeley commented on SOLR-1277:
Been trying to get the cloud branch going... but I'm running into issues
somewhere (BasicZooKeeperTest):
{code}
log4j:WARN No appenders could be found for logger
(org.apache.zookeeper.server.ZooKeeperServerMain).
log4j:WARN Please initialize the log4j system properly.
make:/solr
make:/collections/collection1/config=collection1
put:/configs/collection1/solrconfig.xml solr\conf\solrconfig.xml
make:/configs/collection1/solrconfig.xml
put:/configs/collection1/schema.xml solr\conf\schema.xml
make:/configs/collection1/schema.xml
put:/configs/collection1/stopwords.txt solr\conf\stopwords.txt
make:/configs/collection1/stopwords.txt
put:/configs/collection1/protwords.txt solr\conf\protwords.txt
make:/configs/collection1/protwords.txt
put:/configs/collection1/mapping-ISOLatin1Accent.txt
solr\conf\mapping-ISOLatin1Accent.txt
make:/configs/collection1/mapping-ISOLatin1Accent.txt
put:/configs/collection1/old_synonyms.txt solr\conf\old_synonyms.txt
make:/configs/collection1/old_synonyms.txt
Dec 12, 2009 11:17:42 AM org.apache.solr.AbstractZooKeeperTestCase setUp
INFO: SETUP_START testBasic
look for collection config:/collections/collection1
java.lang.RuntimeException: org.apache.solr.common.SolrException: ZooKeeper
Exception
at org.apache.solr.util.TestHarness.init(TestHarness.java:152)
at
org.apache.solr.AbstractZooKeeperTestCase.setUp(AbstractZooKeeperTestCase.java:81)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90)
Caused by: org.apache.solr.common.SolrException: ZooKeeper Exception
at
org.apache.solr.core.ZooKeeperController.loadConfigPath(ZooKeeperController.java:103)
at
org.apache.solr.core.ZooKeeperController.init(ZooKeeperController.java:48)
at
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:132)
at org.apache.solr.util.TestHarness.init(TestHarness.java:139)
... 19 more
Caused by: org.apache.zookeeper.KeeperException$ConnectionLossException:
KeeperErrorCode = ConnectionLoss for /collections/collection1
at org.apache.zookeeper.KeeperException.create(KeeperException.java:90)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:42)
at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1214)
at
org.apache.solr.core.ZooKeeperController.loadConfigPath(ZooKeeperController.java:91)
... 22 more
{code}
Implement a Solr specific naming service (using Zookeeper)
--
Key: SOLR-1277
URL: https://issues.apache.org/jira/browse/SOLR-1277
Project: Solr
Issue Type: New Feature
Affects Versions: 1.4
Reporter: Jason Rutherglen
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.5
Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch,
SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar
Original Estimate: 672h
Remaining Estimate: 672h
The goal is to give Solr server clusters self-healing attributes
where if a server fails, indexing and searching don't stop and
all of the partitions remain searchable. For configuration, the
ability to centrally deploy a new configuration without servers
going offline.
We can start with basic failover and start from there?
Features:
* Automatic failover (i.e. when a server fails, clients stop
trying to index to or search it)
* Centralized configuration management (i.e. new solrconfig.xml
or schema.xml propagates to a live Solr cluster)
* Optionally allow shards of a partition to be moved to another
server (i.e. if a server gets hot, move the hot segments out to
cooler servers). Ideally we'd have a way to detect hot segments
and move them seamlessly. With NRT this becomes somewhat more
difficult but not impossible?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1651) Incorrect dataimport handler package name in SolrResourceLoader
Incorrect dataimport handler package name in SolrResourceLoader --- Key: SOLR-1651 URL: https://issues.apache.org/jira/browse/SOLR-1651 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Akshay K. Ukey Priority: Trivial Fix For: 1.5 packages String array used by findClass method in SolrResourceLoader has value for dataimport handler package as handler.dataimport, must be handler.dataimport. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1651) Incorrect dataimport handler package name in SolrResourceLoader
[ https://issues.apache.org/jira/browse/SOLR-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akshay K. Ukey updated SOLR-1651: - Attachment: SOLR-1651.patch Incorrect dataimport handler package name in SolrResourceLoader --- Key: SOLR-1651 URL: https://issues.apache.org/jira/browse/SOLR-1651 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Akshay K. Ukey Priority: Trivial Fix For: 1.5 Attachments: SOLR-1651.patch packages String array used by findClass method in SolrResourceLoader has value for dataimport handler package as handler.dataimport, must be handler.dataimport. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789769#action_12789769 ] Yonik Seeley commented on SOLR-1277: Update: seems to pass for me on Linux, but it's failing much of the time on Win7. It's not consistent - it probably passes 20% of the time, but often fails in the middle. Implement a Solr specific naming service (using Zookeeper) -- Key: SOLR-1277 URL: https://issues.apache.org/jira/browse/SOLR-1277 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar Original Estimate: 672h Remaining Estimate: 672h The goal is to give Solr server clusters self-healing attributes where if a server fails, indexing and searching don't stop and all of the partitions remain searchable. For configuration, the ability to centrally deploy a new configuration without servers going offline. We can start with basic failover and start from there? Features: * Automatic failover (i.e. when a server fails, clients stop trying to index to or search it) * Centralized configuration management (i.e. new solrconfig.xml or schema.xml propagates to a live Solr cluster) * Optionally allow shards of a partition to be moved to another server (i.e. if a server gets hot, move the hot segments out to cooler servers). Ideally we'd have a way to detect hot segments and move them seamlessly. With NRT this becomes somewhat more difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1650) Consider being able to cache function results per request
[ https://issues.apache.org/jira/browse/SOLR-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789770#action_12789770 ] patrick o'leary commented on SOLR-1650: --- Can we ensure that function queries have an isCachable method? Distance functions can have a lot of uniqueness (think dragging on a map for setting the center) with a lot of distances attached. Having a generic cache means setting a low cache to avoid distance bloating, would mean lowering the value for other functions queries wanting to use that cache. Consider being able to cache function results per request - Key: SOLR-1650 URL: https://issues.apache.org/jira/browse/SOLR-1650 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 1.5 Once we can sort, filter and boost by functions, it may be the case that the same function is executed for the same value over and over again. Consider ways to cache this information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789771#action_12789771 ] Mark Miller commented on SOLR-1277: --- It looks to me like the ZooKeeper server is shutting down before the test is finished. Will have to get Windows up and running to see why that might be. Implement a Solr specific naming service (using Zookeeper) -- Key: SOLR-1277 URL: https://issues.apache.org/jira/browse/SOLR-1277 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar Original Estimate: 672h Remaining Estimate: 672h The goal is to give Solr server clusters self-healing attributes where if a server fails, indexing and searching don't stop and all of the partitions remain searchable. For configuration, the ability to centrally deploy a new configuration without servers going offline. We can start with basic failover and start from there? Features: * Automatic failover (i.e. when a server fails, clients stop trying to index to or search it) * Centralized configuration management (i.e. new solrconfig.xml or schema.xml propagates to a live Solr cluster) * Optionally allow shards of a partition to be moved to another server (i.e. if a server gets hot, move the hot segments out to cooler servers). Ideally we'd have a way to detect hot segments and move them seamlessly. With NRT this becomes somewhat more difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martijn van Groningen updated SOLR-236: --- Attachment: field-collapse-5.patch @Marc. This was a silly bug, that occurs when you do not define a field collapse cache in the solrconfig.xml. I have attached a patch that fixes this bug, so you can use field collapse without configuring a field collapse cache. Caching with field collapsing is an optional feature. @Chad. Due to changes in the trunk applying the previous patch will result into merge conflicts. The new patch can be applied without merge conflicts. This means that applying this patch on 1.4 source will properly result in merge conflicts. Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Fix For: 1.5 Attachments: collapsing-patch-to-1.3.0-dieter.patch, collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, collapsing-patch-to-1.3.0-ivan_3.patch, field-collapse-3.patch, field-collapse-4-with-solrj.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, field-collapse-solr-236-2.patch, field-collapse-solr-236.patch, field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, quasidistributed.additional.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, solr-236.patch, SOLR-236_collapsing.patch, SOLR-236_collapsing.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1177) Distributed TermsComponent
[ https://issues.apache.org/jira/browse/SOLR-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789790#action_12789790 ] Shalin Shekhar Mangar commented on SOLR-1177: - Thanks Matt. Can you please attach the relevant portions to SOLR-1139. We can commit SOLR-1139 first and then resolve this one. Distributed TermsComponent -- Key: SOLR-1177 URL: https://issues.apache.org/jira/browse/SOLR-1177 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Matt Weber Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 1.5 Attachments: SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, TermsComponent.java, TermsComponent.patch TermsComponent should be distributed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1651) Incorrect dataimport handler package name in SolrResourceLoader
[ https://issues.apache.org/jira/browse/SOLR-1651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-1651: --- Assignee: Shalin Shekhar Mangar Incorrect dataimport handler package name in SolrResourceLoader --- Key: SOLR-1651 URL: https://issues.apache.org/jira/browse/SOLR-1651 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Akshay K. Ukey Assignee: Shalin Shekhar Mangar Priority: Trivial Fix For: 1.5 Attachments: SOLR-1651.patch packages String array used by findClass method in SolrResourceLoader has value for dataimport handler package as handler.dataimport, must be handler.dataimport. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1177) Distributed TermsComponent
[ https://issues.apache.org/jira/browse/SOLR-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789794#action_12789794 ] Matt Weber commented on SOLR-1177: -- The latest SOLR-1139 patch is included inside the latest patch I attached to this ticket. Should I separate them? Distributed TermsComponent -- Key: SOLR-1177 URL: https://issues.apache.org/jira/browse/SOLR-1177 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Matt Weber Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 1.5 Attachments: SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, TermsComponent.java, TermsComponent.patch TermsComponent should be distributed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1177) Distributed TermsComponent
[ https://issues.apache.org/jira/browse/SOLR-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789795#action_12789795 ] Shalin Shekhar Mangar commented on SOLR-1177: - bq. The latest SOLR-1139 patch is included inside the latest patch I attached to this ticket. Should I separate them? Yes. I'll commit SOLR-1139 first so remove those classes from the current patch. PS: I'm sorry if I am confusing you. It is 3AM here and I'm a little confused myself :) Distributed TermsComponent -- Key: SOLR-1177 URL: https://issues.apache.org/jira/browse/SOLR-1177 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Matt Weber Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 1.5 Attachments: SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, TermsComponent.java, TermsComponent.patch TermsComponent should be distributed -- 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] Updated: (SOLR-1139) SolrJ TermsComponent Query and Response Support
[ https://issues.apache.org/jira/browse/SOLR-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Weber updated SOLR-1139: - Attachment: SOLR-1139.patch Updated patch in preparation for SOLR-1177 SolrJ TermsComponent Query and Response Support --- Key: SOLR-1139 URL: https://issues.apache.org/jira/browse/SOLR-1139 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 1.4 Reporter: Matt Weber Assignee: Shalin Shekhar Mangar Priority: Minor Attachments: SOLR-1139-WITH_SORT_SUPPORT.patch, SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch SolrJ should support the new TermsComponent that was introduced in Solr 1.4. It should be able to: - set TermsComponent query parameters via SolrQuery - parse the TermsComponent response -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1177) Distributed TermsComponent
[ https://issues.apache.org/jira/browse/SOLR-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Weber updated SOLR-1177: - Attachment: SOLR-1177.patch New patch that DOES NOT include the code for SOLR-1139. Make sure you have SOLR-1139 applied before using this patch. Distributed TermsComponent -- Key: SOLR-1177 URL: https://issues.apache.org/jira/browse/SOLR-1177 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Matt Weber Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 1.5 Attachments: SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, SOLR-1177.patch, TermsComponent.java, TermsComponent.patch TermsComponent should be distributed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12789803#action_12789803 ] Shalin Shekhar Mangar commented on SOLR-1652: - This capability already exists. Run a single test using: ant -Dtestcase=TestDistributedSearch clean test Run tests inside a package (recursively): ant -Dtestpackage=org.apache.solr.handler clean test Run tests in package root: ant -Dtestpackageroot=org.apache.solr.handler clean test The above will exclude packages inside handler such as admin and component. 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 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-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 ] Grant Ingersoll updated SOLR-1131: -- Attachment: SOLR-1131.patch Missing an in DistanceUtils.parsePoint 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-1650) Consider being able to cache function results per request
[ https://issues.apache.org/jira/browse/SOLR-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789804#action_12789804 ] Grant Ingersoll commented on SOLR-1650: --- I was thinking of a cache whose scope was the length of the request. The basic use case is: 1. Filter by distance 2. Boost/Sort by distance 3. Facet by distance Of course, this could feed the pseudo fields, too. Consider being able to cache function results per request - Key: SOLR-1650 URL: https://issues.apache.org/jira/browse/SOLR-1650 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 1.5 Once we can sort, filter and boost by functions, it may be the case that the same function is executed for the same value over and over again. Consider ways to cache this information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789808#action_12789808 ] Yonik Seeley commented on SOLR-1277: OK, I fixed it for now (rather hacked around it). The zookeeper client startup is asynchronous - if you use it fast enough after creation, you can get a ConnectionLoss (really it never finished establishing it I believe). For now I've just added a sleep of 200ms (100 often wasn't enough). I suppose we should switch to using a Watcher and some sort of wait mechanism when we really need to do a zookeeper operation synchronously. It does bring up the point that we need to think about what we can do when disconnected from zk to... some things we will need to wait for zk, some things we can remember and update zk when we become connected again, and some things we could simply drop. Implement a Solr specific naming service (using Zookeeper) -- Key: SOLR-1277 URL: https://issues.apache.org/jira/browse/SOLR-1277 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar Original Estimate: 672h Remaining Estimate: 672h The goal is to give Solr server clusters self-healing attributes where if a server fails, indexing and searching don't stop and all of the partitions remain searchable. For configuration, the ability to centrally deploy a new configuration without servers going offline. We can start with basic failover and start from there? Features: * Automatic failover (i.e. when a server fails, clients stop trying to index to or search it) * Centralized configuration management (i.e. new solrconfig.xml or schema.xml propagates to a live Solr cluster) * Optionally allow shards of a partition to be moved to another server (i.e. if a server gets hot, move the hot segments out to cooler servers). Ideally we'd have a way to detect hot segments and move them seamlessly. With NRT this becomes somewhat more difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1297) Enable sorting by Function Query
[ https://issues.apache.org/jira/browse/SOLR-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-1297. --- Resolution: Fixed Committed revision 889997. Enable sorting by Function Query Key: SOLR-1297 URL: https://issues.apache.org/jira/browse/SOLR-1297 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: SOLR-1297.patch It would be nice if one could sort by FunctionQuery. See also SOLR-773, where this was first mentioned by Yonik as part of the generic solution to geo-search -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789812#action_12789812 ] Yonik Seeley commented on SOLR-1277: Mark - I notice that you're currently using a zookeeper client per core... was this just easiest to start with, or were there other advantages? A zk client is another connection, and if people run a lot of cores (like AOL does?) then that's a lot of network connections and a lot of ZK pings. Also, we need one ZK client associated with the core container and not any specific core anyway. Implement a Solr specific naming service (using Zookeeper) -- Key: SOLR-1277 URL: https://issues.apache.org/jira/browse/SOLR-1277 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar Original Estimate: 672h Remaining Estimate: 672h The goal is to give Solr server clusters self-healing attributes where if a server fails, indexing and searching don't stop and all of the partitions remain searchable. For configuration, the ability to centrally deploy a new configuration without servers going offline. We can start with basic failover and start from there? Features: * Automatic failover (i.e. when a server fails, clients stop trying to index to or search it) * Centralized configuration management (i.e. new solrconfig.xml or schema.xml propagates to a live Solr cluster) * Optionally allow shards of a partition to be moved to another server (i.e. if a server gets hot, move the hot segments out to cooler servers). Ideally we'd have a way to detect hot segments and move them seamlessly. With NRT this becomes somewhat more difficult but not impossible? -- 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] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789814#action_12789814 ] Henry Robinson commented on SOLR-1277: -- Yonik - You're right, the way to correctly connect is to have a condition variable that can get notified by a watcher fired when the connection to ZK is established. You will also of course need to worry about what happens if the connection is established before you can issue the wait on the condition variable, and you lose the wake-up :) We should maybe think about adding a synchronous connection API to ZooKeeper... Henry Implement a Solr specific naming service (using Zookeeper) -- Key: SOLR-1277 URL: https://issues.apache.org/jira/browse/SOLR-1277 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar Original Estimate: 672h Remaining Estimate: 672h The goal is to give Solr server clusters self-healing attributes where if a server fails, indexing and searching don't stop and all of the partitions remain searchable. For configuration, the ability to centrally deploy a new configuration without servers going offline. We can start with basic failover and start from there? Features: * Automatic failover (i.e. when a server fails, clients stop trying to index to or search it) * Centralized configuration management (i.e. new solrconfig.xml or schema.xml propagates to a live Solr cluster) * Optionally allow shards of a partition to be moved to another server (i.e. if a server gets hot, move the hot segments out to cooler servers). Ideally we'd have a way to detect hot segments and move them seamlessly. With NRT this becomes somewhat more difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789820#action_12789820 ] Mark Miller commented on SOLR-1277: --- bq. Mark - I notice that you're currently using a zookeeper client per core... Hmm ... I shouldn't be. I'll have to look at the code, but I should be making one ZooKeeper component class that holds the ZooKeeper client and then giving the same instance to each core? So each core has a ref to that instance, but it should be the same? I'll have to look at the code again later ... Implement a Solr specific naming service (using Zookeeper) -- Key: SOLR-1277 URL: https://issues.apache.org/jira/browse/SOLR-1277 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar Original Estimate: 672h Remaining Estimate: 672h The goal is to give Solr server clusters self-healing attributes where if a server fails, indexing and searching don't stop and all of the partitions remain searchable. For configuration, the ability to centrally deploy a new configuration without servers going offline. We can start with basic failover and start from there? Features: * Automatic failover (i.e. when a server fails, clients stop trying to index to or search it) * Centralized configuration management (i.e. new solrconfig.xml or schema.xml propagates to a live Solr cluster) * Optionally allow shards of a partition to be moved to another server (i.e. if a server gets hot, move the hot segments out to cooler servers). Ideally we'd have a way to detect hot segments and move them seamlessly. With NRT this becomes somewhat more difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789822#action_12789822 ] Mark Miller commented on SOLR-1277: --- Ok, continued being a rude host and looked right now ;) Yeah, the ref in the core is currently just a convenience. The client belongs to the CoreContainer though. Most of this code is pretty exploratory. Thats why I put the //nocommit above the getZooKeeper method on core - that all has to be considered. Of course you can just use the coreDescriptor to get the corecontainer, and then get the ZooKeeper component. But just for ease right now, the core is holding its own ref - not its own client though. Implement a Solr specific naming service (using Zookeeper) -- Key: SOLR-1277 URL: https://issues.apache.org/jira/browse/SOLR-1277 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar Original Estimate: 672h Remaining Estimate: 672h The goal is to give Solr server clusters self-healing attributes where if a server fails, indexing and searching don't stop and all of the partitions remain searchable. For configuration, the ability to centrally deploy a new configuration without servers going offline. We can start with basic failover and start from there? Features: * Automatic failover (i.e. when a server fails, clients stop trying to index to or search it) * Centralized configuration management (i.e. new solrconfig.xml or schema.xml propagates to a live Solr cluster) * Optionally allow shards of a partition to be moved to another server (i.e. if a server gets hot, move the hot segments out to cooler servers). Ideally we'd have a way to detect hot segments and move them seamlessly. With NRT this becomes somewhat more difficult but not impossible? -- 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-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789822#action_12789822 ] Mark Miller edited comment on SOLR-1277 at 12/12/09 11:46 PM: -- Ok, continued being a rude host and looked right now ;) Yeah, the ref in the core is currently just a convenience. The client belongs to the CoreContainer though. Most of this code is pretty exploratory. Thats why I put the //nocommit above the getZooKeeper method on core - that all has to be considered. Of course you can just use the coreDescriptor to get the corecontainer, and then get the ZooKeeper component. But just for ease right now, the core is holding its own ref - not its own client though. *edit* Though at a minimum, it doesn't make sense to keep the overloaded constructors as is - even if the core is to keep its own ref (which is not necessary, just saves a couple method calls), it would make more sense to pull it off the coredescriptor.getCoreContainer. I just patched that all in real quick at the beginning - currently nothing even uses it. I just put it there real quick when I was considering how component and handlers would access the ZooKeeper component. was (Author: markrmil...@gmail.com): Ok, continued being a rude host and looked right now ;) Yeah, the ref in the core is currently just a convenience. The client belongs to the CoreContainer though. Most of this code is pretty exploratory. Thats why I put the //nocommit above the getZooKeeper method on core - that all has to be considered. Of course you can just use the coreDescriptor to get the corecontainer, and then get the ZooKeeper component. But just for ease right now, the core is holding its own ref - not its own client though. Implement a Solr specific naming service (using Zookeeper) -- Key: SOLR-1277 URL: https://issues.apache.org/jira/browse/SOLR-1277 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Jason Rutherglen Assignee: Grant Ingersoll Priority: Minor Fix For: 1.5 Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar Original Estimate: 672h Remaining Estimate: 672h The goal is to give Solr server clusters self-healing attributes where if a server fails, indexing and searching don't stop and all of the partitions remain searchable. For configuration, the ability to centrally deploy a new configuration without servers going offline. We can start with basic failover and start from there? Features: * Automatic failover (i.e. when a server fails, clients stop trying to index to or search it) * Centralized configuration management (i.e. new solrconfig.xml or schema.xml propagates to a live Solr cluster) * Optionally allow shards of a partition to be moved to another server (i.e. if a server gets hot, move the hot segments out to cooler servers). Ideally we'd have a way to detect hot segments and move them seamlessly. With NRT this becomes somewhat more difficult but not impossible? -- 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.
Re: Synchronizing Webapp on Tomcat with Solr instance
Hi, I think this is a question for the solr-u...@lucene.apache.org mailing list. The solr-dev mailing list is mostly for communication that has to do with Solr internals and development of Solr itself. On Sat, Dec 12, 2009 at 12:34 AM, insaneyogi3008 insaney...@gmail.comwrote: Hello, I have a webapp on Tomcat that displays search results to the end users . I have a Solr instance on the same linux box that has data indexed . The webapp wraps an instance of CommonHTTPSolrServer presumably to send HTTP requests to the Solr instance , now if Solr has indexed documents , how does it return the document(s) that satisfied the search query ? I am a little confused about how this communication between tomcat solr takes place -- View this message in context: http://old.nabble.com/Synchronizing-Webapp-on-Tomcat-with-Solr-instance-tp26754143p26754143.html Sent from the Solr - Dev mailing list archive at Nabble.com. -- Good Enough is not good enough. To give anything less than your best is to sacrifice the gift. Quality First. Measure Twice. Cut Once. http://www.israelekpo.com/
[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.
