[jira] Updated: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-647: Attachment: SOLR-647.patch > Do SolrCore.close() in a refcounted way > --- > > Key: SOLR-647 > URL: https://issues.apache.org/jira/browse/SOLR-647 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul >Priority: Minor > Attachments: SOLR-647.patch > > > The method _SolrCore.close()_ directly closes the core . It can cause > Exceptions for in-flight requests. The _close()_ method should just do a > decrement on refcount and the actual close must happen when the last request > being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-662) support all highlighter parameters in solr-ruby
[
https://issues.apache.org/jira/browse/SOLR-662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-662:
Attachment: SOLR-662.patch
For backward compatibility, the patch supports both formats:
{code:[EMAIL PROTECTED]:highlighting][:max_snippets]}
:highlighting => {
:max_snippets => 3
}
{code}
{code:[EMAIL PROTECTED]:highlighting][:max_snippets]}
:highlighting => {
:max_snippets => {
:default=>2,:fields=>{'author'=>3}
}
}
{code}
> support all highlighter parameters in solr-ruby
> ---
>
> Key: SOLR-662
> URL: https://issues.apache.org/jira/browse/SOLR-662
> Project: Solr
> Issue Type: Improvement
> Components: clients - ruby - flare
>Affects Versions: 1.3
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-662.patch
>
>
> At present solr-ruby doesn't support the following hl functions:
> * per-field override
> ** hl.snippets
> ** hl.fragsize
> ** hl.requireFieldMatch
> ** hl.simple.pre
> ** hl.simple.post
> * non-per-field-override
> ** hl.alternateField
> ** hl.maxAlternateFieldLength
> * other hl parameters
> ** hl.maxAnalyzedChars (w/ *per-field override*)
> ** hl.usePhraseHighlighter
> ** hl.mergeContiguous (w/ *per-field override*)
> ** hl.increment (w/ *per-field override*)
> ** hl.formatter (w/ *per-field override*)
> ** hl.fragmenter (w/ *per-field override*)
> ** hl.regex.slop (w/ *per-field override*)
> ** hl.regex.pattern (w/ *per-field override*)
> ** hl.regex.maxAnalyzedChars (w/ *per-field override*)
> A patch supports these functions will be shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-662) support all highlighter parameters in solr-ruby
support all highlighter parameters in solr-ruby --- Key: SOLR-662 URL: https://issues.apache.org/jira/browse/SOLR-662 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Affects Versions: 1.3 Reporter: Koji Sekiguchi Priority: Minor At present solr-ruby doesn't support the following hl functions: * per-field override ** hl.snippets ** hl.fragsize ** hl.requireFieldMatch ** hl.simple.pre ** hl.simple.post * non-per-field-override ** hl.alternateField ** hl.maxAlternateFieldLength * other hl parameters ** hl.maxAnalyzedChars (w/ *per-field override*) ** hl.usePhraseHighlighter ** hl.mergeContiguous (w/ *per-field override*) ** hl.increment (w/ *per-field override*) ** hl.formatter (w/ *per-field override*) ** hl.fragmenter (w/ *per-field override*) ** hl.regex.slop (w/ *per-field override*) ** hl.regex.pattern (w/ *per-field override*) ** hl.regex.maxAnalyzedChars (w/ *per-field override*) A patch supports these functions will be shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-660) Simplify UpdateRequestProcessor API
[ https://issues.apache.org/jira/browse/SOLR-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617119#action_12617119 ] Ryan McKinley commented on SOLR-660: bq. I guess it would be nice to make the UpdateRequestProcessorFactory any UpdateRequestProcessorFactory that needs access to SolrCore just needs to implement SolrCoreAware, then it will be initialized via the standard plugin stuff. Our base UpdateRequestProcessorFactory should not need SolrCore. It does not _need_ to be a factory, but the chaining and state implementations (for non-trivial processors) is much more straight forward. > Simplify UpdateRequestProcessor API > --- > > Key: SOLR-660 > URL: https://issues.apache.org/jira/browse/SOLR-660 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-660-update-processor.patch > > > SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration > is too complicated and should be simplified before release 1.3 -- 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-660) Simplify UpdateRequestProcessor API
[ https://issues.apache.org/jira/browse/SOLR-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617118#action_12617118 ] noble.paul edited comment on SOLR-660 at 7/25/08 8:06 PM: -- This looks very good, Ryan .The configuration is obvious as what it is doing though I'm still not convinced of the need for a factory (Eitherway it does not matter). I guess it would be nice to make the _UpdateRequestProcessorFactory_ implements SolrCoreAware. Any initialization with the core can be done here. I have changed the wiki too was (Author: noble.paul): This looks very good, Ryan .The configuration is obvious as what is is doing . I guess it would be nice to make the _UpdateRequestProcessorFactory_ implements SolrCoreAware. Any initialization with the core can be done here > Simplify UpdateRequestProcessor API > --- > > Key: SOLR-660 > URL: https://issues.apache.org/jira/browse/SOLR-660 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-660-update-processor.patch > > > SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration > is too complicated and should be simplified before release 1.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-660) Simplify UpdateRequestProcessor API
[ https://issues.apache.org/jira/browse/SOLR-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617118#action_12617118 ] Noble Paul commented on SOLR-660: - This looks very good, Ryan .The configuration is obvious as what is is doing . I guess it would be nice to make the _UpdateRequestProcessorFactory_ implements SolrCoreAware. Any initialization with the core can be done here > Simplify UpdateRequestProcessor API > --- > > Key: SOLR-660 > URL: https://issues.apache.org/jira/browse/SOLR-660 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-660-update-processor.patch > > > SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration > is too complicated and should be simplified before release 1.3 -- 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-660) Simplify UpdateRequestProcessor API
[
https://issues.apache.org/jira/browse/SOLR-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617016#action_12617016
]
ryantxu edited comment on SOLR-660 at 7/25/08 5:32 PM:
-
patch that removes the no-op factory and forces eveything to be a chain. Now
the configuration looks like this:
{code:xml}
x1
x2
{code}
The big changes are:
* processor factories are now loaded with NamedListInitalizedPluginLoader --
it is no longer custon Node parsing.
* the Factories no longer have direct access to core. if they need it, they
can implement SorlCoreAware
* moves all config parsing out of the processor classes.
was (Author: ryantxu):
patch that removes the no-op factory and forces eveything to be a chain.
Now the configuration looks like this:
{code:xml}
x1
x2
{code}
The big changes are:
* processor factories are now loaded with NamedListInitalizedPluginLoader --
it is no longer custon Node parsing.
* the Factories no longer have direct access to core. if they need it, they
can implement SorlCoreAware
* moves all config parsing out of the processor classes.
> Simplify UpdateRequestProcessor API
> ---
>
> Key: SOLR-660
> URL: https://issues.apache.org/jira/browse/SOLR-660
> Project: Solr
> Issue Type: Improvement
> Components: update
>Affects Versions: 1.3
>Reporter: Ryan McKinley
> Fix For: 1.3
>
> Attachments: SOLR-660-update-processor.patch
>
>
> SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration
> is too complicated and should be simplified before release 1.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-660) Simplify UpdateRequestProcessor API
[ https://issues.apache.org/jira/browse/SOLR-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-660. Resolution: Fixed just committed this and updated the text on: http://wiki.apache.org/solr/UpdateRequestProcessor Shalin, if you could add more documentation / comments from your experience using it, that would be great. > Simplify UpdateRequestProcessor API > --- > > Key: SOLR-660 > URL: https://issues.apache.org/jira/browse/SOLR-660 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-660-update-processor.patch > > > SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration > is too complicated and should be simplified before release 1.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-661) NPE in SpellingQueryConverter when used with q.alt=*:*
[
https://issues.apache.org/jira/browse/SOLR-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-661.
Resolution: Fixed
Fix Version/s: 1.3
fixed in 679925.
thanks Kalyan
> NPE in SpellingQueryConverter when used with q.alt=*:*
> --
>
> Key: SOLR-661
> URL: https://issues.apache.org/jira/browse/SOLR-661
> Project: Solr
> Issue Type: Bug
>Reporter: Kalyan Manepalli
>Assignee: Ryan McKinley
> Fix For: 1.3
>
>
> SpellingQueryConverter throws NPE when used with q.alt=*:*
> The issue being the String original will be passed as null when q.alt=*:*. I
> think the required behavior should be when original string is null, just
> return the empty result.
> Here is the code snippet with suggested change
> {code}
> public Collection convert(String original) {
> Collection result = new ArrayList();
> if(original ==null){ //usecase with q.alt=*:*
> return result;
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-661) NPE in SpellingQueryConverter when used with q.alt=*:*
[
https://issues.apache.org/jira/browse/SOLR-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-661:
--
Assignee: Ryan McKinley
> NPE in SpellingQueryConverter when used with q.alt=*:*
> --
>
> Key: SOLR-661
> URL: https://issues.apache.org/jira/browse/SOLR-661
> Project: Solr
> Issue Type: Bug
>Reporter: Kalyan Manepalli
>Assignee: Ryan McKinley
>
> SpellingQueryConverter throws NPE when used with q.alt=*:*
> The issue being the String original will be passed as null when q.alt=*:*. I
> think the required behavior should be when original string is null, just
> return the empty result.
> Here is the code snippet with suggested change
> {code}
> public Collection convert(String original) {
> Collection result = new ArrayList();
> if(original ==null){ //usecase with q.alt=*:*
> return result;
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-661) NPE in SpellingQueryConverter when used with q.alt=*:*
NPE in SpellingQueryConverter when used with q.alt=*:*
--
Key: SOLR-661
URL: https://issues.apache.org/jira/browse/SOLR-661
Project: Solr
Issue Type: Bug
Reporter: Kalyan Manepalli
SpellingQueryConverter throws NPE when used with q.alt=*:*
The issue being the String original will be passed as null when q.alt=*:*. I
think the required behavior should be when original string is null, just return
the empty result.
Here is the code snippet with suggested change
{code}
public Collection convert(String original) {
Collection result = new ArrayList();
if(original ==null){ //usecase with q.alt=*:*
return result;
}
{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-660) Simplify UpdateRequestProcessor API
[ https://issues.apache.org/jira/browse/SOLR-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617027#action_12617027 ] Shalin Shekhar Mangar commented on SOLR-660: Thanks for opening this issue Ryan! The configuration looks much better and going with the NamedListInitializedPlugin and SolrCoreAware makes it more consistent with the RequestHandler and SearchComponent code base. Let me see how I can help :) > Simplify UpdateRequestProcessor API > --- > > Key: SOLR-660 > URL: https://issues.apache.org/jira/browse/SOLR-660 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-660-update-processor.patch > > > SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration > is too complicated and should be simplified before release 1.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-660) Simplify UpdateRequestProcessor API
[ https://issues.apache.org/jira/browse/SOLR-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-660: --- Summary: Simplify UpdateRequestProcessor API (was: Simlify UpdateRequestProcessor API) > Simplify UpdateRequestProcessor API > --- > > Key: SOLR-660 > URL: https://issues.apache.org/jira/browse/SOLR-660 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-660-update-processor.patch > > > SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration > is too complicated and should be simplified before release 1.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-660) Simlify UpdateRequestProcessor API
[
https://issues.apache.org/jira/browse/SOLR-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-660:
---
Attachment: SOLR-660-update-processor.patch
patch that removes the no-op factory and forces eveything to be a chain. Now
the configuration looks like this:
{code:xml}
x1
x2
{code}
The big changes are:
* processor factories are now loaded with NamedListInitalizedPluginLoader --
it is no longer custon Node parsing.
* the Factories no longer have direct access to core. if they need it, they
can implement SorlCoreAware
* moves all config parsing out of the processor classes.
> Simlify UpdateRequestProcessor API
> --
>
> Key: SOLR-660
> URL: https://issues.apache.org/jira/browse/SOLR-660
> Project: Solr
> Issue Type: Improvement
> Components: update
>Affects Versions: 1.3
>Reporter: Ryan McKinley
> Fix For: 1.3
>
> Attachments: SOLR-660-update-processor.patch
>
>
> SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration
> is too complicated and should be simplified before release 1.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-660) Simlify UpdateRequestProcessor API
Simlify UpdateRequestProcessor API -- Key: SOLR-660 URL: https://issues.apache.org/jira/browse/SOLR-660 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Reporter: Ryan McKinley Fix For: 1.3 SOLR-269 introduced UpdateRequestProcessor. The existing API/configuration is too complicated and should be simplified before release 1.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (SOLR-645) Move facet tests into own class
: I'm sorry about the excess email traffic -- I thought/hoped that JIRA would : suppress sending the notifications if I bulk modified the issues. It's not big deal ... i think there is a "don't send mail" option that you have to explicitly look for & check in order to get that behavior when bulk modifing. : I just closed them because I accidentially hovered over the "resolved" icon and : it said something like "pending verification until closed", so I thought closing : them would be the proper way to do it. Like i said ... no biggee ... Jira has a lot of quirks. -Hoss
[jira] Issue Comment Edited: (SOLR-620) Velocity Response Writer
[
https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616969#action_12616969
]
ryantxu edited comment on SOLR-620 at 7/25/08 10:51 AM:
--
the JSON feature gets around a javascript limitation for cross-site scripting.
If you enclose your HTML within a JSON tag, you can access from any server --
otherwise it has to come from the same machine.
the json feature just sends your velocity template output (perhaps html)
surrounded with:
{code}
{ result: "your template output here (escaped for json)" }
{code}
was (Author: ryantxu):
the JSON feature gets around a javascript limitation for cross-site
scripting. If you enclose your HTML within a JSON tag, you can access from any
server -- otherwise it has to come from the same machine.
the json feature just sends your velocity template output (perhaps html)
surrounded with:
{\"result\":\"" + json encoded output + "\"}
> Velocity Response Writer
>
>
> Key: SOLR-620
> URL: https://issues.apache.org/jira/browse/SOLR-620
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 1.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch,
> SOLR-620.patch
>
>
> Add a Velocity - http://velocity.apache.org - response writer, making it
> possible to generate a decent search UI straight from Solr itself. Designed
> to work standalone or in conjunction with the JSON response writer (or
> SolrJS) for Ajaxy things.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-620) Velocity Response Writer
[
https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616969#action_12616969
]
Ryan McKinley commented on SOLR-620:
the JSON feature gets around a javascript limitation for cross-site scripting.
If you enclose your HTML within a JSON tag, you can access from any server --
otherwise it has to come from the same machine.
the json feature just sends your velocity template output (perhaps html)
surrounded with:
{\"result\":\"" + json encoded output + "\"}
> Velocity Response Writer
>
>
> Key: SOLR-620
> URL: https://issues.apache.org/jira/browse/SOLR-620
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 1.3
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch,
> SOLR-620.patch
>
>
> Add a Velocity - http://velocity.apache.org - response writer, making it
> possible to generate a decent search UI straight from Solr itself. Designed
> to work standalone or in conjunction with the JSON response writer (or
> SolrJS) for Ajaxy things.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
[ https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616966#action_12616966 ] Noble Paul commented on SOLR-269: - The idea is to make the API simple. If a Processor wishes to create a state object , it is easier to do it without a factory than with a factory. The user has to care about very few interfaces. I can draw parallels with Servlet Filter. Users write very complex filters and I have never seen people complaining about it not having a factory . SolrDispatchFilter is a very good example. If it is simple enough people will use it. If it is complex only the 'very smart people' use it. Most of the users are not power users and they just want to get things done. On Fri, Jul 25, 2008 at 10:27 PM, Shalin Shekhar Mangar (JIRA) -- --Noble Paul > UpdateRequestProcessorFactory - process requests before submitting them > --- > > Key: SOLR-269 > URL: https://issues.apache.org/jira/browse/SOLR-269 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-269-simple.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, UpdateProcessor.patch > > > A simple UpdateRequestProcessor was added to a bloated SOLR-133 commit. > An UpdateRequestProcessor lets clients plug in logic after a document has > been parsed and before it has been 'updated' with the index. This is a good > place to add custom logic for: > * transforming the document fields > * fine grained authorization (can user X updated document Y?) > * allow update, but not delete (by query?) > > name="update.processor.class">org.apache.solr.handler.UpdateRequestProcessor > > ... (optionally pass in arguments to the factory init method) ... > > > http://www.nabble.com/Re%3A-svn-commit%3A-r547495---in--lucene-solr-trunk%3A-example-solr-conf-solrconfig.xml-src-java-org-apache-solr-handler-StaxUpdateRequestHandler.java-src-java-org-apache-solr-handler-UpdateRequestProcessor.jav-tf3950072.html#a11206583 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-620) Velocity Response Writer
[ https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616953#action_12616953 ] Erik Hatcher commented on SOLR-620: --- Matthias - I'm perplexed by the JSON feature. The intention was to use the Velocity writer to produce templated output, but if you want JSON data, use wt=json, not the velocity one. > Velocity Response Writer > > > Key: SOLR-620 > URL: https://issues.apache.org/jira/browse/SOLR-620 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch, > SOLR-620.patch > > > Add a Velocity - http://velocity.apache.org - response writer, making it > possible to generate a decent search UI straight from Solr itself. Designed > to work standalone or in conjunction with the JSON response writer (or > SolrJS) for Ajaxy things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
[ https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616949#action_12616949 ] Shalin Shekhar Mangar commented on SOLR-269: bq. This gets overly complex too... do we add a special init() function? would everything need a factory, but it may or may not be used? No, why would we need special methods or a factory? Just the init/inform will be fine. Just that they would be called once in their scope. Am I missing something? I don't really care about sharing objects across requests. My motivation is only to help make the API simpler. bq. Consider the buffering example... how would I be able to call all buffered functions on finish()? What if I want a processor to make sure only one document is sent at a time? I see your point here. The next UpdateProcessor or a Servlet FilterChain like design will be necessary in that case. Let me think more on this since I've obviously under-estimated the use-cases for this API. I always thought that one should do heavy-duty processing like authentication etc. on the client side before sending documents to Solr or else one should extend/write an UpdateHandler. > UpdateRequestProcessorFactory - process requests before submitting them > --- > > Key: SOLR-269 > URL: https://issues.apache.org/jira/browse/SOLR-269 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-269-simple.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, UpdateProcessor.patch > > > A simple UpdateRequestProcessor was added to a bloated SOLR-133 commit. > An UpdateRequestProcessor lets clients plug in logic after a document has > been parsed and before it has been 'updated' with the index. This is a good > place to add custom logic for: > * transforming the document fields > * fine grained authorization (can user X updated document Y?) > * allow update, but not delete (by query?) > > name="update.processor.class">org.apache.solr.handler.UpdateRequestProcessor > > ... (optionally pass in arguments to the factory init method) ... > > > http://www.nabble.com/Re%3A-svn-commit%3A-r547495---in--lucene-solr-trunk%3A-example-solr-conf-solrconfig.xml-src-java-org-apache-solr-handler-StaxUpdateRequestHandler.java-src-java-org-apache-solr-handler-UpdateRequestProcessor.jav-tf3950072.html#a11206583 -- 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-269) UpdateRequestProcessorFactory - process requests before submitting them
[ https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616932#action_12616932 ] ryantxu edited comment on SOLR-269 at 7/25/08 9:14 AM: - bq. A "request" scope will create the chain or individual processor for each request so that you may maintain state without using request's context. Otherwise, it will be created once and re-used for all requests. Will that solve this problem? --To me, that makes it more confusing then having each processor call next() explicitly...-- (dooh - answering the wrong question) This gets overly complex too... do we add a special init() function? would everything need a factory, but it may or may not be used? If the motivation for making the objects shared across requests is clarity, i'm not sure it helps. Is there some other reason? bq. In Noble's patch, instead of calling super.processXXX method, you can return true/false to signal or avoid chaining. but then how would a processor be able to continue the chain? Consider the buffering example... how would I be able to call all buffered functions on finish()? What if I want a processor to make sure only one document is sent at a time? was (Author: ryantxu): bq. A "request" scope will create the chain or individual processor for each request so that you may maintain state without using request's context. Otherwise, it will be created once and re-used for all requests. Will that solve this problem? To me, that makes it more confusing then having each processor call next() explicitly... bq. In Noble's patch, instead of calling super.processXXX method, you can return true/false to signal or avoid chaining. but then how would a processor be able to continue the chain? Consider the buffering example... how would I be able to call all buffered functions on finish()? What if I want a processor to make sure only one document is sent at a time? > UpdateRequestProcessorFactory - process requests before submitting them > --- > > Key: SOLR-269 > URL: https://issues.apache.org/jira/browse/SOLR-269 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-269-simple.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, UpdateProcessor.patch > > > A simple UpdateRequestProcessor was added to a bloated SOLR-133 commit. > An UpdateRequestProcessor lets clients plug in logic after a document has > been parsed and before it has been 'updated' with the index. This is a good > place to add custom logic for: > * transforming the document fields > * fine grained authorization (can user X updated document Y?) > * allow update, but not delete (by query?) > > name="update.processor.class">org.apache.solr.handler.UpdateRequestProcessor > > ... (optionally pass in arguments to the factory init method) ... > > > http://www.nabble.com/Re%3A-svn-commit%3A-r547495---in--lucene-solr-trunk%3A-example-solr-conf-solrconfig.xml-src-java-org-apache-solr-handler-StaxUpdateRequestHandler.java-src-java-org-apache-solr-handler-UpdateRequestProcessor.jav-tf3950072.html#a11206583 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
[ https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616932#action_12616932 ] Ryan McKinley commented on SOLR-269: bq. A "request" scope will create the chain or individual processor for each request so that you may maintain state without using request's context. Otherwise, it will be created once and re-used for all requests. Will that solve this problem? To me, that makes it more confusing then having each processor call next() explicitly... bq. In Noble's patch, instead of calling super.processXXX method, you can return true/false to signal or avoid chaining. but then how would a processor be able to continue the chain? Consider the buffering example... how would I be able to call all buffered functions on finish()? What if I want a processor to make sure only one document is sent at a time? > UpdateRequestProcessorFactory - process requests before submitting them > --- > > Key: SOLR-269 > URL: https://issues.apache.org/jira/browse/SOLR-269 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-269-simple.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, UpdateProcessor.patch > > > A simple UpdateRequestProcessor was added to a bloated SOLR-133 commit. > An UpdateRequestProcessor lets clients plug in logic after a document has > been parsed and before it has been 'updated' with the index. This is a good > place to add custom logic for: > * transforming the document fields > * fine grained authorization (can user X updated document Y?) > * allow update, but not delete (by query?) > > name="update.processor.class">org.apache.solr.handler.UpdateRequestProcessor > > ... (optionally pass in arguments to the factory init method) ... > > > http://www.nabble.com/Re%3A-svn-commit%3A-r547495---in--lucene-solr-trunk%3A-example-solr-conf-solrconfig.xml-src-java-org-apache-solr-handler-StaxUpdateRequestHandler.java-src-java-org-apache-solr-handler-UpdateRequestProcessor.jav-tf3950072.html#a11206583 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616929#action_12616929
]
Shalin Shekhar Mangar commented on SOLR-269:
bq. I think that removing the factories does not simplify things... most
processors that do interesting things will need to parse some request arguments
and keep some state. So they will end up with a separate object that is looked
up in the Context (and created if it's not there and stuffed into the Context).
Same number of classes, but maybe even a little more complex.
How about giving this independence through configuration?
{code:xml}
{code}
A "request" scope will create the chain or individual processor for each
request so that you may maintain state without using request's context.
Otherwise, it will be created once and re-used for all requests. Will that
solve this problem?
bq. We lose power by removing the explicit calling of "next" by components. I
actually have a component that needs to buffer up some documents and pass them
down the chain in batches later. I think Ryan might have something like this
too.
In Noble's patch, instead of calling super.processXXX method, you can return
true/false to signal or avoid chaining.
> UpdateRequestProcessorFactory - process requests before submitting them
> ---
>
> Key: SOLR-269
> URL: https://issues.apache.org/jira/browse/SOLR-269
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: SOLR-269-simple.patch,
> SOLR-269-UpdateRequestProcessorFactory.patch,
> SOLR-269-UpdateRequestProcessorFactory.patch,
> SOLR-269-UpdateRequestProcessorFactory.patch, UpdateProcessor.patch
>
>
> A simple UpdateRequestProcessor was added to a bloated SOLR-133 commit.
> An UpdateRequestProcessor lets clients plug in logic after a document has
> been parsed and before it has been 'updated' with the index. This is a good
> place to add custom logic for:
> * transforming the document fields
> * fine grained authorization (can user X updated document Y?)
> * allow update, but not delete (by query?)
>
> name="update.processor.class">org.apache.solr.handler.UpdateRequestProcessor
>
> ... (optionally pass in arguments to the factory init method) ...
>
>
> http://www.nabble.com/Re%3A-svn-commit%3A-r547495---in--lucene-solr-trunk%3A-example-solr-conf-solrconfig.xml-src-java-org-apache-solr-handler-StaxUpdateRequestHandler.java-src-java-org-apache-solr-handler-UpdateRequestProcessor.jav-tf3950072.html#a11206583
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
[ https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616927#action_12616927 ] Ryan McKinley commented on SOLR-269: I also like the simplified syntax, and I think the parent should always be a 'chain' -- this can get rid of some of the ugliness. But the power of the chain model is that each link can take over control without the others needing to know. For example, I have a processor that validates everything in the request before passing it on to next processors. To do this, it reads them all in without passing them down the chain and only continues when finish() is called. I also don't see a problem with the factory model. creating a factory is no more/less difficult then creating a special 'state' object that gets put into the context. But the the context option, the state is always a Map call away rather them being right there. Now you have to worry about what key you used etc... > UpdateRequestProcessorFactory - process requests before submitting them > --- > > Key: SOLR-269 > URL: https://issues.apache.org/jira/browse/SOLR-269 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-269-simple.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, UpdateProcessor.patch > > > A simple UpdateRequestProcessor was added to a bloated SOLR-133 commit. > An UpdateRequestProcessor lets clients plug in logic after a document has > been parsed and before it has been 'updated' with the index. This is a good > place to add custom logic for: > * transforming the document fields > * fine grained authorization (can user X updated document Y?) > * allow update, but not delete (by query?) > > name="update.processor.class">org.apache.solr.handler.UpdateRequestProcessor > > ... (optionally pass in arguments to the factory init method) ... > > > http://www.nabble.com/Re%3A-svn-commit%3A-r547495---in--lucene-solr-trunk%3A-example-solr-conf-solrconfig.xml-src-java-org-apache-solr-handler-StaxUpdateRequestHandler.java-src-java-org-apache-solr-handler-UpdateRequestProcessor.jav-tf3950072.html#a11206583 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
[ https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616923#action_12616923 ] Yonik Seeley commented on SOLR-269: --- While I like the syntax of the config (getting rid of explicit chained update processor), I'm not sure about the internal changes: - I think that removing the factories does not simplify things... most processors that do interesting things will need to parse some request arguments and keep some state. So they will end up with a separate object that is looked up in the Context (and created if it's not there and stuffed into the Context). Same number of classes, but maybe even a little more complex. - We lose power by removing the explicit calling of "next" by components. I actually have a component that needs to buffer up some documents and pass them down the chain in batches later. I think Ryan might have something like this too. > UpdateRequestProcessorFactory - process requests before submitting them > --- > > Key: SOLR-269 > URL: https://issues.apache.org/jira/browse/SOLR-269 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-269-simple.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, > SOLR-269-UpdateRequestProcessorFactory.patch, UpdateProcessor.patch > > > A simple UpdateRequestProcessor was added to a bloated SOLR-133 commit. > An UpdateRequestProcessor lets clients plug in logic after a document has > been parsed and before it has been 'updated' with the index. This is a good > place to add custom logic for: > * transforming the document fields > * fine grained authorization (can user X updated document Y?) > * allow update, but not delete (by query?) > > name="update.processor.class">org.apache.solr.handler.UpdateRequestProcessor > > ... (optionally pass in arguments to the factory init method) ... > > > http://www.nabble.com/Re%3A-svn-commit%3A-r547495---in--lucene-solr-trunk%3A-example-solr-conf-solrconfig.xml-src-java-org-apache-solr-handler-StaxUpdateRequestHandler.java-src-java-org-apache-solr-handler-UpdateRequestProcessor.jav-tf3950072.html#a11206583 -- 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-648) SpellcheckComponent throws NullPointerException on restart without build
[ https://issues.apache.org/jira/browse/SOLR-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616907#action_12616907 ] shalinmangar edited comment on SOLR-648 at 7/25/08 7:39 AM: - Committed revision 679816. Thanks Jonathan and Geoffrey! was (Author: shalinmangar): Committed. Thanks Jonathan and Geoffrey! > SpellcheckComponent throws NullPointerException on restart without build > > > Key: SOLR-648 > URL: https://issues.apache.org/jira/browse/SOLR-648 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Geoffrey Young >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: SOLR-648.patch, SOLR-648.patch, SOLR-648.patch > > > from > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200807.mbox/[EMAIL > PROTECTED] > "I believe there is a bug in IndexBased- and FileBasedSpellChecker.java > where the analyzer variable is only set on the build command. Therefore, > when the index is reloaded, but not built after starting solr, issuing a > query with the spellcheck.q parameter will cause a NullPointerException to > be thrown (SpellCheckComponent.java:158). Moving the analyzer logic to the > constructor seems to fix the problem." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-653) remove "overwrite" command from solrj API
[ https://issues.apache.org/jira/browse/SOLR-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616910#action_12616910 ] Ryan McKinley commented on SOLR-653: it should only keep the last document in the list... the first would be overwritten by the last. > remove "overwrite" command from solrj API > - > > Key: SOLR-653 > URL: https://issues.apache.org/jira/browse/SOLR-653 > Project: Solr > Issue Type: Improvement > Components: clients - java >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-653-remove-solrj-overwrite.patch > > > The solrj API should not expose the 'overwrite' option. Using it will most > likely cause errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-653) remove "overwrite" command from solrj API
[ https://issues.apache.org/jira/browse/SOLR-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616909#action_12616909 ] Fuad Efendi commented on SOLR-653: -- Thanks Ryan, Another question, add(Collection docs) - what may happen if Collection contains documents with same uniqueKey? > remove "overwrite" command from solrj API > - > > Key: SOLR-653 > URL: https://issues.apache.org/jira/browse/SOLR-653 > Project: Solr > Issue Type: Improvement > Components: clients - java >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > Attachments: SOLR-653-remove-solrj-overwrite.patch > > > The solrj API should not expose the 'overwrite' option. Using it will most > likely cause errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-648) SpellcheckComponent throws NullPointerException on restart without build
[ https://issues.apache.org/jira/browse/SOLR-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-648. Resolution: Fixed Committed. Thanks Jonathan and Geoffrey! > SpellcheckComponent throws NullPointerException on restart without build > > > Key: SOLR-648 > URL: https://issues.apache.org/jira/browse/SOLR-648 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Geoffrey Young >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: SOLR-648.patch, SOLR-648.patch, SOLR-648.patch > > > from > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200807.mbox/[EMAIL > PROTECTED] > "I believe there is a bug in IndexBased- and FileBasedSpellChecker.java > where the analyzer variable is only set on the build command. Therefore, > when the index is reloaded, but not built after starting solr, issuing a > query with the spellcheck.q parameter will cause a NullPointerException to > be thrown (SpellCheckComponent.java:158). Moving the analyzer logic to the > constructor seems to fix the problem." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-659) Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr
[
https://issues.apache.org/jira/browse/SOLR-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616903#action_12616903
]
Brian Whitman commented on SOLR-659:
An example of a bulk query using this patch. Without this patch such bulk
queries will eventually time out or cause exceptions in the server as too much
data is passed back and forth.
{code:java}
public SolrDocumentList blockQuery(SolrQuery q, int blockSize, int maxResults) {
SolrDocumentList allResults = new SolrDocumentList();
if(blockSize > maxResults) { blockSize = maxResults; }
for(int i=0; i maxResults) { break; }
}
if(allResults.size() > maxResults) { break; }
}
return allResults;
}
{code}
> Explicitly set start and rows per shard for more efficient bulk queries
> across distributed Solr
> ---
>
> Key: SOLR-659
> URL: https://issues.apache.org/jira/browse/SOLR-659
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Brian Whitman
>Priority: Minor
> Fix For: 1.3
>
> Attachments: shards.start_rows.patch
>
>
> The default behavior of setting start and rows on distributed solr (SOLR-303)
> is to set start at 0 across all shards and set rows to start+rows across each
> shard. This ensures all results are returned for any arbitrary start and rows
> setting, but during "bulk queries" (where start is incrementally increased
> and rows is kept consistent) the client would need finer control of the
> per-shard start and rows parameter as retrieving many thousands of documents
> becomes intractable as start grows higher.
> Attaching a patch that creates a &shards.start and &shards.rows parameter. If
> used, the logic that sets rows to start+rows per shard is overridden and each
> shard gets the exact start and rows set in shards.start and shards.rows. The
> client will receive up to shards.rows * nShards results and should set rows
> accordingly. This makes bulk queries across distributed solr possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-620) Velocity Response Writer
[ https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Epheser updated SOLR-620: -- Attachment: SOLR-620.patch According to the patches Ryan mentioned above (SOLR-641 and SOLR-654, I created an update of VelocityResponseWriter. It now contains the following configuration possibilities: - vl.template: The template file to use inside conf/velocity/ - vl.json: If this param is true, the output of the template is wrapped inside a javascript function, eg myFunction( ). This is necessary if we want to use JSON requests out of a javascript client. - vl.content: The content type of the response. Default is text/html in standard mode, and text/json in vl.json=true mode. - vl.response: To provide an implementation of SolrResponse inside the template, specify the class name of the implementation. For convenience, it looks inside the package "org.apache.solr.client.solrj.response", so you only have to choose eg. QueryResponse, LukeResponse, MultiCoreResponse. Custom classes may be accessed using the full qualified class name, eg. my.custom.package.CustomResponse Regardless of the vl.response, there is always an instance of RawRequestHelper inside the context, this provides access to the SolrQueryRequest and SolrQueryResponse, as well as convenience methods like getResultIterator() or getRequestParam() > Velocity Response Writer > > > Key: SOLR-620 > URL: https://issues.apache.org/jira/browse/SOLR-620 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Attachments: SOLR-620.jars.zip, SOLR-620.patch, SOLR-620.patch, > SOLR-620.patch > > > Add a Velocity - http://velocity.apache.org - response writer, making it > possible to generate a decent search UI straight from Solr itself. Designed > to work standalone or in conjunction with the JSON response writer (or > SolrJS) for Ajaxy things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-659) Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr
Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr --- Key: SOLR-659 URL: https://issues.apache.org/jira/browse/SOLR-659 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Brian Whitman Priority: Minor Fix For: 1.3 Attachments: shards.start_rows.patch The default behavior of setting start and rows on distributed solr (SOLR-303) is to set start at 0 across all shards and set rows to start+rows across each shard. This ensures all results are returned for any arbitrary start and rows setting, but during "bulk queries" (where start is incrementally increased and rows is kept consistent) the client would need finer control of the per-shard start and rows parameter as retrieving many thousands of documents becomes intractable as start grows higher. Attaching a patch that creates a &shards.start and &shards.rows parameter. If used, the logic that sets rows to start+rows per shard is overridden and each shard gets the exact start and rows set in shards.start and shards.rows. The client will receive up to shards.rows * nShards results and should set rows accordingly. This makes bulk queries across distributed solr possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-659) Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr
[ https://issues.apache.org/jira/browse/SOLR-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-659: --- Attachment: shards.start_rows.patch Attaching patch. > Explicitly set start and rows per shard for more efficient bulk queries > across distributed Solr > --- > > Key: SOLR-659 > URL: https://issues.apache.org/jira/browse/SOLR-659 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Brian Whitman >Priority: Minor > Fix For: 1.3 > > Attachments: shards.start_rows.patch > > > The default behavior of setting start and rows on distributed solr (SOLR-303) > is to set start at 0 across all shards and set rows to start+rows across each > shard. This ensures all results are returned for any arbitrary start and rows > setting, but during "bulk queries" (where start is incrementally increased > and rows is kept consistent) the client would need finer control of the > per-shard start and rows parameter as retrieving many thousands of documents > becomes intractable as start grows higher. > Attaching a patch that creates a &shards.start and &shards.rows parameter. If > used, the logic that sets rows to start+rows per shard is overridden and each > shard gets the exact start and rows set in shards.start and shards.rows. The > client will receive up to shards.rows * nShards results and should set rows > accordingly. This makes bulk queries across distributed solr possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-648) SpellcheckComponent throws NullPointerException on restart without build
[ https://issues.apache.org/jira/browse/SOLR-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616892#action_12616892 ] Shalin Shekhar Mangar commented on SOLR-648: Yes, I've added a testcase which fails otherwise. > SpellcheckComponent throws NullPointerException on restart without build > > > Key: SOLR-648 > URL: https://issues.apache.org/jira/browse/SOLR-648 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Geoffrey Young >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: SOLR-648.patch, SOLR-648.patch, SOLR-648.patch > > > from > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200807.mbox/[EMAIL > PROTECTED] > "I believe there is a bug in IndexBased- and FileBasedSpellChecker.java > where the analyzer variable is only set on the build command. Therefore, > when the index is reloaded, but not built after starting solr, issuing a > query with the spellcheck.q parameter will cause a NullPointerException to > be thrown (SpellCheckComponent.java:158). Moving the analyzer logic to the > constructor seems to fix the problem." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-648) SpellcheckComponent throws NullPointerException on restart without build
[ https://issues.apache.org/jira/browse/SOLR-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616889#action_12616889 ] Grant Ingersoll commented on SOLR-648: -- I perused the patch and it looks reasonable since we are just getting the ResourceLoader from the Core there anyway. It does look like we should add a test case for this issue. > SpellcheckComponent throws NullPointerException on restart without build > > > Key: SOLR-648 > URL: https://issues.apache.org/jira/browse/SOLR-648 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Geoffrey Young >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: SOLR-648.patch, SOLR-648.patch, SOLR-648.patch > > > from > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200807.mbox/[EMAIL > PROTECTED] > "I believe there is a bug in IndexBased- and FileBasedSpellChecker.java > where the analyzer variable is only set on the build command. Therefore, > when the index is reloaded, but not built after starting solr, issuing a > query with the spellcheck.q parameter will cause a NullPointerException to > be thrown (SpellCheckComponent.java:158). Moving the analyzer logic to the > constructor seems to fix the problem." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-506) Enabling HTTP Cache headers should be configurable on a per-handler basis
[ https://issues.apache.org/jira/browse/SOLR-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-506: --- Attachment: SOLR-506.patch Syncing the patch with the trunk. No other changes to the code base. Hoss -- Do we need anything more in this patch? > Enabling HTTP Cache headers should be configurable on a per-handler basis > - > > Key: SOLR-506 > URL: https://issues.apache.org/jira/browse/SOLR-506 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Hoss Man > Fix For: 1.3 > > Attachments: SOLR-506.patch, SOLR-506.patch, SOLR-506.patch > > > HTTP cache headers are needed only for select handler's response and it does > not make much sense to enable it globally for all Solr responses. > Therefore, enabling/disabling cache headers should be configurable on a > per-handler basis. It should be enabled by default on the select request > handler and disabled by default on all others. It should be possible to > override these defaults through configuration as well as through API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-648) SpellcheckComponent throws NullPointerException on restart without build
[ https://issues.apache.org/jira/browse/SOLR-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-648: --- Attachment: SOLR-648.patch Added testcase as SpellCheckComponentTest#testReloadOnStart which reproduces the bug reported in this issue. Grant, would you like to review this patch? It contains minor API change so you'll need to revisit the custom SolrSpellChecker implementation you had. I'd like to commit this asap so that I can continue with SOLR-622. An alternate way would have been to change the signature of the SolrSpellChecker.reload method to take in atleast the SolrCore or the same params as the build method. > SpellcheckComponent throws NullPointerException on restart without build > > > Key: SOLR-648 > URL: https://issues.apache.org/jira/browse/SOLR-648 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Geoffrey Young >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: SOLR-648.patch, SOLR-648.patch, SOLR-648.patch > > > from > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200807.mbox/[EMAIL > PROTECTED] > "I believe there is a bug in IndexBased- and FileBasedSpellChecker.java > where the analyzer variable is only set on the build command. Therefore, > when the index is reloaded, but not built after starting solr, issuing a > query with the spellcheck.q parameter will cause a NullPointerException to > be thrown (SpellCheckComponent.java:158). Moving the analyzer logic to the > constructor seems to fix the problem." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-609) SpellCheckComponent doesn't read default options from solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-609. -- Resolution: Fixed > SpellCheckComponent doesn't read default options from solrconfig.xml > > > Key: SOLR-609 > URL: https://issues.apache.org/jira/browse/SOLR-609 > Project: Solr > Issue Type: Bug > Components: spellchecker >Affects Versions: 1.3 > Environment: confirmed on FreeBSD7-stable , nightly 1.3 build > (2008-06-25) , jdk1.6. > I am using the spellchecker called as last-components from my dismax handler. >Reporter: Norberto Meijome >Assignee: Grant Ingersoll >Priority: Minor > Attachments: SOLR-609.patch > > > solrconfig.xml contains : > [...] >class="org.apache.solr.handler.component.SpellCheckComponent"> > > > false > > true > > 1 > > true > > [... all default options after this] > confirmed options .count , collate , extendedResults set in solrconfig.xml > take no effect on the query . They work as intended if added to the URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Closed: (SOLR-645) Move facet tests into own class
I'm sorry about the excess email traffic -- I thought/hoped that JIRA would suppress sending the notifications if I bulk modified the issues. I just closed them because I accidentially hovered over the "resolved" icon and it said something like "pending verification until closed", so I thought closing them would be the proper way to do it. Lars
[jira] Work started: (SOLR-648) SpellcheckComponent throws NullPointerException on restart without build
[ https://issues.apache.org/jira/browse/SOLR-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SOLR-648 started by Shalin Shekhar Mangar. > SpellcheckComponent throws NullPointerException on restart without build > > > Key: SOLR-648 > URL: https://issues.apache.org/jira/browse/SOLR-648 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Geoffrey Young >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: SOLR-648.patch, SOLR-648.patch > > > from > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200807.mbox/[EMAIL > PROTECTED] > "I believe there is a bug in IndexBased- and FileBasedSpellChecker.java > where the analyzer variable is only set on the build command. Therefore, > when the index is reloaded, but not built after starting solr, issuing a > query with the spellcheck.q parameter will cause a NullPointerException to > be thrown (SpellCheckComponent.java:158). Moving the analyzer logic to the > constructor seems to fix the problem." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-648) SpellcheckComponent throws NullPointerException on restart without build
[ https://issues.apache.org/jira/browse/SOLR-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-648: --- Attachment: SOLR-648.patch This fixes the NullPointerException. The changes are: * The signature of the init method is changed to init(NamedList, SolrCore) * All analyzer defining code is moved to AbstractLuceneSpellChecker#init from the build methods in IndexBasedSpellChecker and FileBasedSpellChecker. I'll add a test and then give another patch shortly. > SpellcheckComponent throws NullPointerException on restart without build > > > Key: SOLR-648 > URL: https://issues.apache.org/jira/browse/SOLR-648 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Geoffrey Young >Assignee: Shalin Shekhar Mangar > Fix For: 1.3 > > Attachments: SOLR-648.patch, SOLR-648.patch > > > from > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200807.mbox/[EMAIL > PROTECTED] > "I believe there is a bug in IndexBased- and FileBasedSpellChecker.java > where the analyzer variable is only set on the build command. Therefore, > when the index is reloaded, but not built after starting solr, issuing a > query with the spellcheck.q parameter will cause a NullPointerException to > be thrown (SpellCheckComponent.java:158). Moving the analyzer logic to the > constructor seems to fix the problem." -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-658) Allow Solr to load index from arbitrary directory in dataDir and Commit point
[ https://issues.apache.org/jira/browse/SOLR-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-658: -- Assignee: Shalin Shekhar Mangar > Allow Solr to load index from arbitrary directory in dataDir and Commit point > - > > Key: SOLR-658 > URL: https://issues.apache.org/jira/browse/SOLR-658 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > > This is a requirement for java based Solr replication > Usecase for arbitrary index directory: > if the slave has a corrupted index and the filesystem does not allow > overwriting files in use (NTFS) replication will fail. The solution is to > copy the index from master to an alternate directory on slave and load > indexreader/indexwriter from this alternate directory. > Usecase for arbitrary commitpoint : > Replication can also provide rollback feature . The rollback should be able > to mention a comitpoint /generation so that rollback is possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-658) Allow Solr to load index from arbitrary directory in dataDir and Commit point
[ https://issues.apache.org/jira/browse/SOLR-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616801#action_12616801 ] Noble Paul commented on SOLR-658: - Implementation * keep a file index.properties in the data dir * Have an entry index= in that file * This file may also keep _version_ * When a new indexsearcher/writer is loaded, read this property and try to load the index from that folder * if it is absent , default to the hardcoded value for index and latest commitpoint > Allow Solr to load index from arbitrary directory in dataDir and Commit point > - > > Key: SOLR-658 > URL: https://issues.apache.org/jira/browse/SOLR-658 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul > > This is a requirement for java based Solr replication > Usecase for arbitrary index directory: > if the slave has a corrupted index and the filesystem does not allow > overwriting files in use (NTFS) replication will fail. The solution is to > copy the index from master to an alternate directory on slave and load > indexreader/indexwriter from this alternate directory. > Usecase for arbitrary commitpoint : > Replication can also provide rollback feature . The rollback should be able > to mention a comitpoint /generation so that rollback is possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-658) Allow Solr to load index from arbitrary directory in dataDir and Commit point
Allow Solr to load index from arbitrary directory in dataDir and Commit point - Key: SOLR-658 URL: https://issues.apache.org/jira/browse/SOLR-658 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Noble Paul This is a requirement for java based Solr replication Usecase for arbitrary index directory: if the slave has a corrupted index and the filesystem does not allow overwriting files in use (NTFS) replication will fail. The solution is to copy the index from master to an alternate directory on slave and load indexreader/indexwriter from this alternate directory. Usecase for arbitrary commitpoint : Replication can also provide rollback feature . The rollback should be able to mention a comitpoint /generation so that rollback is possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-657) Replace deprecated calls with the non-deprecated equivalents
[ https://issues.apache.org/jira/browse/SOLR-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Kotthoff updated SOLR-657: --- Attachment: SOLR-657-impl-depr.patch Attaching second patch (SOLR-657-impl-depr.patch) which adds @Deprecation annotations and @deprecation javadoc to methods in SolrQueryRequestBase which are deprecated in the interface this class implements, SolrQueryRequest. Quite a lot of classes use the implementation directly instead of the interface. > Replace deprecated calls with the non-deprecated equivalents > > > Key: SOLR-657 > URL: https://issues.apache.org/jira/browse/SOLR-657 > Project: Solr > Issue Type: Task >Affects Versions: 1.3 >Reporter: Lars Kotthoff > Attachments: SOLR-657-impl-depr.patch, SOLR-657.patch > > > There are numerous calls to deprecated constructors and methods in the code > base. This includes deprecations from Solr itself, Lucene, and Java. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
[
https://issues.apache.org/jira/browse/SOLR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-269:
Attachment: SOLR-269-simple.patch
A very simple implementation. No factory. No state
The attached patch has not removed the existing stuff and it is not a working
model . But it demonstrates how you can put in a simpler API . The design is
inspired by the _ServletFilter_ API. but without the _filterChain.doFilter()_
part.(it relies on the return code)
The configuration format is
{code:xml}
{code}
The usage must be as follows
{code:java}
solrCore.getUpdateProcessorChain(name).processXXX(command, solrQueryRequest,
solrQueryResponse);
{code}
this patch relies on SOLR-614 for simplifying configuration
> UpdateRequestProcessorFactory - process requests before submitting them
> ---
>
> Key: SOLR-269
> URL: https://issues.apache.org/jira/browse/SOLR-269
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: SOLR-269-simple.patch,
> SOLR-269-UpdateRequestProcessorFactory.patch,
> SOLR-269-UpdateRequestProcessorFactory.patch,
> SOLR-269-UpdateRequestProcessorFactory.patch, UpdateProcessor.patch
>
>
> A simple UpdateRequestProcessor was added to a bloated SOLR-133 commit.
> An UpdateRequestProcessor lets clients plug in logic after a document has
> been parsed and before it has been 'updated' with the index. This is a good
> place to add custom logic for:
> * transforming the document fields
> * fine grained authorization (can user X updated document Y?)
> * allow update, but not delete (by query?)
>
> name="update.processor.class">org.apache.solr.handler.UpdateRequestProcessor
>
> ... (optionally pass in arguments to the factory init method) ...
>
>
> http://www.nabble.com/Re%3A-svn-commit%3A-r547495---in--lucene-solr-trunk%3A-example-solr-conf-solrconfig.xml-src-java-org-apache-solr-handler-StaxUpdateRequestHandler.java-src-java-org-apache-solr-handler-UpdateRequestProcessor.jav-tf3950072.html#a11206583
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
