[jira] Commented: (SOLR-1850) KeepWordFilter can be slow at query time if wordlist is large
[
https://issues.apache.org/jira/browse/SOLR-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850377#action_12850377
]
John Wang commented on SOLR-1850:
-
Hi Yonk:
No problem! Do you think overloading the constructor is the right thing to
do here?
-John
> KeepWordFilter can be slow at query time if wordlist is large
> -
>
> Key: SOLR-1850
> URL: https://issues.apache.org/jira/browse/SOLR-1850
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: John Wang
>
> In the case when "Set words" is large, constructing a KeepWordFilter
> at query time is very costly because of the construction (copy) of the set,
> e.g.:
> this.words = new CharArraySet(words, ignoreCase);
> This call does an addAll on the set, and is done for each query, and is the
> same work.
> Suggestion: overload the constructor and expose the CharArraySet, e.g.:
> public KeepWordFilter(TokenStream in, CharArraySet words ) {
> super(in);
> this.words = words;
> this.termAtt = (TermAttribute)addAttribute(TermAttribute.class);
> }
> This allows the ability to have CharArraySet to be constructed once staticly
> for the application instead at query time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1850) KeepWordFilter can be slow at query time if wordlist is large
KeepWordFilter can be slow at query time if wordlist is large
-
Key: SOLR-1850
URL: https://issues.apache.org/jira/browse/SOLR-1850
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Affects Versions: 1.4
Reporter: John Wang
In the case when "Set words" is large, constructing a KeepWordFilter at
query time is very costly because of the construction (copy) of the set, e.g.:
this.words = new CharArraySet(words, ignoreCase);
This call does an addAll on the set, and is done for each query, and is the
same work.
Suggestion: overload the constructor and expose the CharArraySet, e.g.:
public KeepWordFilter(TokenStream in, CharArraySet words ) {
super(in);
this.words = words;
this.termAtt = (TermAttribute)addAttribute(TermAttribute.class);
}
This allows the ability to have CharArraySet to be constructed once staticly
for the application instead at query time.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1802) Make Solr work with IndexReaderFactory implementations that return MultiReader
[ https://issues.apache.org/jira/browse/SOLR-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843922#action_12843922 ] John Wang commented on SOLR-1802: - Thanks Mark for the pointer! > Make Solr work with IndexReaderFactory implementations that return MultiReader > -- > > Key: SOLR-1802 > URL: https://issues.apache.org/jira/browse/SOLR-1802 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: John Wang > > When an IndexReaderFactory returns an instance of MultiReader, various places > in Solr try to call reader.directory() and reader.getVersion, which results > an UnsupportedOperationException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1807) UpdateHandler plugin is not fully supported
[
https://issues.apache.org/jira/browse/SOLR-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843362#action_12843362
]
John Wang commented on SOLR-1807:
-
bq. I almost think thats the lessor of two evils. While it breaks impls, those
impls cannot fully work with Solr anyway.
I agree 100%
bq. ReplicationHandler
This is a terrific idea. This separates the concern with indexing updating and
replication.
> UpdateHandler plugin is not fully supported
> ---
>
> Key: SOLR-1807
> URL: https://issues.apache.org/jira/browse/SOLR-1807
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 1.4
>Reporter: John Wang
>
> UpdateHandler is published as a supported Plugin, but code such as the
> following:
> if (core.getUpdateHandler() instanceof DirectUpdateHandler2) {
> ((DirectUpdateHandler2)
> core.getUpdateHandler()).forceOpenWriter();
> } else {
> LOG.warn("The update handler being used is not an instance or
> sub-class of DirectUpdateHandler2. " +
> "Replicate on Startup cannot work.");
> }
> suggest that it is really not fully supported.
> Must all implementations of UpdateHandler be subclasses of
> DirectUpdateHandler2 for it to work with replication?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1808) When IndexReader.reopen is called, old reader is not properly closed
[
https://issues.apache.org/jira/browse/SOLR-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843361#action_12843361
]
John Wang commented on SOLR-1808:
-
Thanks Mark and Chris. I meant to close this bug, but kept forgetting it.
Thanks for explaining.
On the same node, Solr is maintaining a heavy weight Searcher instance, but the
search related information is stored with reader. This is especially important
with lucene 2.9 where segmented readers are more exposed. Do you guys still
think having heavy SolrIndexSearcher instances is a good thing?
Anyway, no problem with closing this issue.
> When IndexReader.reopen is called, old reader is not properly closed
>
>
> Key: SOLR-1808
> URL: https://issues.apache.org/jira/browse/SOLR-1808
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.4
>Reporter: John Wang
>
> According to Lucene documentation:
> "If the index has not changed since this instance was (re)opened, then this
> call is a NOOP and returns this instance. Otherwise, a new instance is
> returned. The old instance is not closed and remains usable."
> In SolrCore.java:
> if (newestSearcher != null && solrConfig.reopenReaders
> && indexDirFile.equals(newIndexDirFile)) {
> IndexReader currentReader = newestSearcher.get().getReader();
> IndexReader newReader = currentReader.reopen();
> if (newReader == currentReader) {
> currentReader.incRef();
> }
> tmp = new SolrIndexSearcher(this, schema, "main", newReader, true,
> true);
> }
> When currentReader!=newReader, currentReader seems to be leaking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1808) When IndexReader.reopen is called, old reader is not properly closed
When IndexReader.reopen is called, old reader is not properly closed
Key: SOLR-1808
URL: https://issues.apache.org/jira/browse/SOLR-1808
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.4
Reporter: John Wang
According to Lucene documentation:
"If the index has not changed since this instance was (re)opened, then this
call is a NOOP and returns this instance. Otherwise, a new instance is
returned. The old instance is not closed and remains usable."
In SolrCore.java:
if (newestSearcher != null && solrConfig.reopenReaders
&& indexDirFile.equals(newIndexDirFile)) {
IndexReader currentReader = newestSearcher.get().getReader();
IndexReader newReader = currentReader.reopen();
if (newReader == currentReader) {
currentReader.incRef();
}
tmp = new SolrIndexSearcher(this, schema, "main", newReader, true,
true);
}
When currentReader!=newReader, currentReader seems to be leaking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1807) UpdateHandler plugin is not fully supported
UpdateHandler plugin is not fully supported
---
Key: SOLR-1807
URL: https://issues.apache.org/jira/browse/SOLR-1807
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 1.4
Reporter: John Wang
UpdateHandler is published as a supported Plugin, but code such as the
following:
if (core.getUpdateHandler() instanceof DirectUpdateHandler2) {
((DirectUpdateHandler2) core.getUpdateHandler()).forceOpenWriter();
} else {
LOG.warn("The update handler being used is not an instance or
sub-class of DirectUpdateHandler2. " +
"Replicate on Startup cannot work.");
}
suggest that it is really not fully supported.
Must all implementations of UpdateHandler be subclasses of DirectUpdateHandler2
for it to work with replication?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1802) Make Solr work with IndexReaderFactory implementations that return MultiReader
[ https://issues.apache.org/jira/browse/SOLR-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840010#action_12840010 ] John Wang commented on SOLR-1802: - Thanks Chris for the info. > Make Solr work with IndexReaderFactory implementations that return MultiReader > -- > > Key: SOLR-1802 > URL: https://issues.apache.org/jira/browse/SOLR-1802 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: John Wang > > When an IndexReaderFactory returns an instance of MultiReader, various places > in Solr try to call reader.directory() and reader.getVersion, which results > an UnsupportedOperationException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1802) Solr is not friend to IndexReaderFactory implementations that return MultiReader
Solr is not friend to IndexReaderFactory implementations that return MultiReader Key: SOLR-1802 URL: https://issues.apache.org/jira/browse/SOLR-1802 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Reporter: John Wang When an IndexReaderFactory returns an instance of MultiReader, Solr tries to call reader.directory() and reader.getVersion, which results an UnsupportedOperationException. Custom IndexReaderFactory implementations that return MultiReader instances are common, and I don't there there are documentations that discourage this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1774) IndexReaderFactory should have a close() method for cleanup
IndexReaderFactory should have a close() method for cleanup --- Key: SOLR-1774 URL: https://issues.apache.org/jira/browse/SOLR-1774 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.4 Reporter: John Wang The custom IndexReaderFactory may choose to pool some resources that needs to be cleaned up. IndexReaderFactory should contract a new method, e.g. close() such that when called, the implementation can choose to do some cleanup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custom code to create custom IndexReaders
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605447#action_12605447
]
John Wang commented on SOLR-243:
Sorry, I didn't see Hoss's earlier comments.
Thanks
-John
> Create a hook to allow custom code to create custom IndexReaders
>
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
> Environment: Solr core
>Reporter: John Wang
>Assignee: Hoss Man
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custom code to create custom IndexReaders
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602844#action_12602844
]
John Wang commented on SOLR-243:
Not sure what do you mean?It was supposed to be a simple addition.
-John
> Create a hook to allow custom code to create custom IndexReaders
>
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
> Environment: Solr core
>Reporter: John Wang
>Assignee: Hoss Man
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custom code to create custom IndexReaders
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576693#action_12576693
]
John Wang commented on SOLR-243:
What is the plan for this patch?
We have a couple of votes for it.
Thanks
-John
> Create a hook to allow custom code to create custom IndexReaders
>
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549654
]
John Wang commented on SOLR-243:
Thanks Kevin!
Please vote on this patch to have it committed.
-John
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-390) HashDocSet initialization of internal array is not efficient
[ https://issues.apache.org/jira/browse/SOLR-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539863 ] John Wang commented on SOLR-390: Hi Yonik: With my tests, for large arrays, e.g. 2M entries, there is a 14% gain. But it is 14% out of a small number, so I guess it is not a big deal. Sorry for the false alarm. -John > HashDocSet initialization of internal array is not efficient > > > Key: SOLR-390 > URL: https://issues.apache.org/jira/browse/SOLR-390 > Project: Solr > Issue Type: Bug > Components: search >Reporter: John Wang > > HashDocSet initializes the internal array but iterating it instead of using > Arrays.fill which is much faster. Patch included -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-390) HashDocSet initialization of internal array is not efficient
[ https://issues.apache.org/jira/browse/SOLR-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537051 ] John Wang commented on SOLR-390: I am having problems with "Attach file" Following is the patch: Index: /Users/john/plum/solr-trunk/src/java/org/apache/solr/search/HashDocSet.java === --- /Users/john/plum/solr-trunk/src/java/org/apache/solr/search/HashDocSet.java (revision 587538) +++ /Users/john/plum/solr-trunk/src/java/org/apache/solr/search/HashDocSet.java (working copy) @@ -17,6 +17,8 @@ package org.apache.solr.search; +import java.util.Arrays; + import org.apache.solr.util.BitUtil; @@ -63,8 +65,8 @@ mask=tsize-1; table = new int[tsize]; -for (int i=tsize-1; i>=0; i--) table[i]=EMPTY; - +//for (int i=tsize-1; i>=0; i--) table[i]=EMPTY; +Arrays.fill(table, EMPTY); for (int i=offset; i HashDocSet initialization of internal array is not efficient > > > Key: SOLR-390 > URL: https://issues.apache.org/jira/browse/SOLR-390 > Project: Solr > Issue Type: Bug > Components: search >Reporter: John Wang > > HashDocSet initializes the internal array but iterating it instead of using > Arrays.fill which is much faster. Patch included -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-390) HashDocSet initialization of internal array is not efficient
HashDocSet initialization of internal array is not efficient Key: SOLR-390 URL: https://issues.apache.org/jira/browse/SOLR-390 Project: Solr Issue Type: Bug Components: search Reporter: John Wang HashDocSet initializes the internal array but iterating it instead of using Arrays.fill which is much faster. Patch included -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wang updated SOLR-243:
---
Attachment: indexReaderFactory.patch
My apologies for not being patient with this process.
I have made the requested changes and submitted another patch.
Please let me know if these are the correct things to do.
Thanks
-John
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503697
]
John Wang commented on SOLR-243:
Are you looking at the right patch?
For 1) at least, they are public.
2) I am using Config.findClass
3) I just picked one from your suggestions, mainIndex is fine.
I feel I am jumping through quite a few arbitrary hoops just to contribute to
an open source project, and this is wrong and defeats the whole purpose of the
idea of open source.
I think being more constructive and result oriented instead of being difficult
and purist can benefit this project much more.
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500262
]
John Wang commented on SOLR-243:
My motivation in doing this is to create a plugin into solr for my project:
www.browseengine.com
or
bobo-browse.sourceforge.net
which is a more extensive facetted search implementation. I need a special
IndexReader to do the plugin.
Please take a look.
Thanks
-John
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500261
]
John Wang commented on SOLR-243:
Hi Yonik:
1) context in factory: I am not sure how the interface would look like,
suggestions?
2) I catch the exception to default to the normal IndexReader.open mechanism.
3) I just picked it to be an interface, I think making it an abstract class is
fine.
thanks
-John
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wang updated SOLR-243:
---
Attachment: indexReaderFactory.patch
New patch incorporating Chris's comments 1-6.
for item 3) config is now placed under indexDefaults section.
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499294
]
John Wang commented on SOLR-243:
1) Sorry about this, my eclipse IDE showed 2 spaces. I will remember in the
future.
2) Sorry about this one as well, I changed them from public to private to do
some testing and forgot to change them back. I have no problem with them being
public.
3) That sounds good. I just picked a spot in solrConfig.xml
4) Sure.
5) I think that is a coding style, but I am not religious about it.
6) That is a great idea! I wanted to add this but wasn't sure how to do it.
7) Ok.
Thanks for the code review!
-John
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wang updated SOLR-243:
---
Attachment: indexReaderFactory.patch
I have attached a patch for this issue.
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wang updated SOLR-243:
---
Description:
I have a customized IndexReader and I want to write a Solr plugin to use my
derived IndexReader implementation. Currently IndexReader instantiation is hard
coded to be:
IndexReader.open(path)
It would be really useful if this is done thru a plugable factory that can be
configured, e.g. IndexReaderFactory
interface IndexReaderFactory{
IndexReader newReader(String name,String path);
}
the default implementation would just return: IndexReader.open(path)
And in the newSearcher and getSearcher methods in SolrCore class can call the
current factory implementation to get the IndexReader instance and then build
the SolrIndexSearcher by passing in the reader.
It would be really nice to add this improvement soon (This seems to be a
trivial addition) as our project really depends on this.
Thanks
-John
was:
I have a customized IndexReader and I want to write a Solr plugin to use my
derived IndexReader implementation. Currently IndexReader instantiation is hard
coded to be:
> Create a hook to allow custome code to create custome index readers
> ---
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Fix For: 1.3
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-243) Create a hook to allow custome code to create custome index readers
Create a hook to allow custome code to create custome index readers --- Key: SOLR-243 URL: https://issues.apache.org/jira/browse/SOLR-243 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Environment: Solr core Reporter: John Wang Fix For: 1.3 I have a customized IndexReader and I want to write a Solr plugin to use my derived IndexReader implementation. Currently IndexReader instantiation is hard coded to be: -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
