[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#action_12510574 ] Ryan McKinley commented on SOLR-269: > I don't see any code allowing initialization of the transform chain, or > anything like that. > What are you proposing? Check the latest patch. I'm not sure we need to have XML configuration for this, but I added it as an example. The factory would hold a list of transformers: > Is there a downside to the logging being separated out in this case? only that it justifies the UpdateRequestProcessorFactory chain ;) - - - - - This patch includes a UpdateRequestProcessorChainFactory - this is a UpdateRequestProcessorFactory that keeps a chain of UpdateRequestProcessorFactories and iterates through them. This pointed out another thing I don't like about the chain pattern. I need a custom UpdateRequestProcessor that checks all the requests before executing any of them. I plan to store the valid commands in a list and only execute them in the finish() call. I'm not sure how to map that plan to an chain. How would I pass the output from one processor to the next? > 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-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] 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 ] Ryan McKinley updated SOLR-269: --- Attachment: SOLR-269-UpdateRequestProcessorFactory.patch * loads UpdateRequestProcessorFactories using the plugin loader stuff from SOLR-260. * makes a UpdateRequestHandlerBase class that XML and CSV share. * loads and configures a chain of InputTransformations. * moves UpdateRequestProcessor from o.a.s.handler to o.a.s.update This is the test config: v1 v2 000 111 I am not sure we want to make the transformer interface public yet, but it is here to show how I think it could be handled. If you like this approach, I'll clean it up some more... > 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-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#action_12510563 ] Ryan McKinley commented on SOLR-269: > perhaps the extra functionality of transformations and updating should be > pushed into the UpdateHandler interface That was the first SOLR-139 design! Having thought about it for a while, i think there are nice advantages to keeping the updating/modifying outside of the UpdateHandler - the biggest one is that various RequestHandlers *could* transform the document differently. I'm putting together a hybrid example that (I hope) answers questions about chains/configuration/transformation, etc. I'll post it shortly. > 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-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] Updated: (SOLR-287) set commitMaxTime when adding a document
[ https://issues.apache.org/jira/browse/SOLR-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-287: --- Summary: set commitMaxTime when adding a document (was: set commitMaxTime when adding a single document) sorry, bad title. This adds a maxCommitTime to the AddUpdateCommand - that only takes one document at at time, but the command is shared between everything updated together. As implemented, If you post 1000 docs in a single request with an maxCommitTime=500. It will fire a commit 500ms after the first document is added - even if there are still more coming. > set commitMaxTime when adding a document > > > Key: SOLR-287 > URL: https://issues.apache.org/jira/browse/SOLR-287 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Attachments: SOLR-287-AddCommitMaxTime.patch > > > Rather then setting a global autoCommit maxTime, it would be nice to set a > maximum time for a single add command. This patch adds: > > ... > > to add the document within 1 sec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-287) set commitMaxTime when adding a single document
[ https://issues.apache.org/jira/browse/SOLR-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510551 ] Yonik Seeley commented on SOLR-287: --- why is this linked to a "single document"? Or do you mean a single add command which may contain multiple documents? > set commitMaxTime when adding a single document > --- > > Key: SOLR-287 > URL: https://issues.apache.org/jira/browse/SOLR-287 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Priority: Minor > Attachments: SOLR-287-AddCommitMaxTime.patch > > > Rather then setting a global autoCommit maxTime, it would be nice to set a > maximum time for a single add command. This patch adds: > > ... > > to add the document within 1 sec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-267) log handler + query + hits
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510550
]
Yonik Seeley commented on SOLR-267:
---
The double logging issue with the new update handler framework should be fixed
with whatever mechanism is created here.
Using the responseHeader as logging info is clever, but I'm not sure if we want
to be bound to return everything in the response that we want to be logged (for
updates, some may want all of the ids logged but not returned, and if they are
returned, not in the header).
So, what about either a "NamedList toLog;"on the SolrQueryResponse, or
SolrQueryRequest.getContext().get("log") => NamedList ?
> new patch to promote responseHeader from a defacto standard to an api
> standard in SolrQueryResponse.
I think that's probably OK
> log handler + query + hits
> --
>
> Key: SOLR-267
> URL: https://issues.apache.org/jira/browse/SOLR-267
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Will Johnson
>Priority: Minor
> Fix For: 1.3
>
> Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch,
> LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch,
> LogQueryHitCounts.patch
>
>
> adds a logger to log handler, query string and hit counts for each query
--
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#action_12510538 ] Yonik Seeley commented on SOLR-269: --- > with update processors, the needed interface to add a document changes... you > need the processor rather than the update handler. Thinking on these lines a bit further... perhaps the extra functionality of transformations and updating should be pushed into the UpdateHandler interface (DUH2). If it makes sense, we could deprecate the existing AddUpdateCommand & methods in favor of new ones that use SolrInputDocument. > 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-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#action_12510518 ] Yonik Seeley commented on SOLR-269: --- > This all works nicely with a simple 'transform' chain. I don't see any code allowing initialization of the transform chain, or anything like that. What are you proposing? I think it gets tougher when one talks about updates rather than document adds too. > Isn't logging best configured with standard java.util.logging settings? Not if you want a different type... for example, you seemed to want timing per-document added for example. Having log specific configuration (such as number of ids to log in a big add) in it's own processor seems slightly nicer too. Is there a downside to the logging being separated out in this case? I really don't have strong feelings about it though (as long as we can keep the default version lean enough). > I see what you are getting at, but makes the basic cases more complicated > then it needs to be. Yes, with the upside that we know our transform interface isn't too limiting. > I'm reluctant to add another plugin layer Me too... which is why just doing transform with the processors seems desirable (one less type of plugin). If transformations are not to be done with UpdateRequestProcessor, I'm not sure we should expose that interface at all as it's tightly coupled with DUH2. It seems we really only need one type of plugin to do these document transformations. > SolrCore could have a single UpdateRequestProcessorFactory that handlers > could use as the default. Yes, with update processors, the needed interface to add a document changes... you need the processor rather than the update handler. > 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-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.
LICENSE.txt nitpick?
Is line 189 of LICENSE.txt supposed to say something other then: Copyright [] [name of copyright owner] ?
[jira] Commented: (SOLR-290) Boost property in QueryParameter class not a Float
[ https://issues.apache.org/jira/browse/SOLR-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510513 ] Jeff Rodenburg commented on SOLR-290: - Fix applied in revision #141 @ http://solrstuff.org/svn/solrsharp. > Boost property in QueryParameter class not a Float > -- > > Key: SOLR-290 > URL: https://issues.apache.org/jira/browse/SOLR-290 > Project: Solr > Issue Type: Bug > Components: clients - C# >Affects Versions: 1.2 >Reporter: Jeff Rodenburg >Priority: Minor > Fix For: 1.2 > > > The Boost property on the QueryParameter class in SolrSharp is of type Int, > while the Lucene specification uses types Float. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-290) Boost property in QueryParameter class not a Float
Boost property in QueryParameter class not a Float -- Key: SOLR-290 URL: https://issues.apache.org/jira/browse/SOLR-290 Project: Solr Issue Type: Bug Components: clients - C# Affects Versions: 1.2 Reporter: Jeff Rodenburg Priority: Minor Fix For: 1.2 The Boost property on the QueryParameter class in SolrSharp is of type Int, while the Lucene specification uses types Float. -- 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#action_12510510 ] Ryan McKinley commented on SOLR-269: > Some other issues how to configure processors for multiple update > handlers? Perhaps allow configuration of a global default for update handlers > with no processors specified? That would make it easy to make sure your > custom processor was used everywhere. SolrCore could have a single UpdateRequestProcessorFactory that handlers could use as the default. I'm reluctant to add another plugin layer, but this would make it easier to share with the CSV update handler and others. Since its a factory, it will be thread safe across multiple handlers. Again, I'm reluctant to think about configuring a processor chain in solrconfig.xml -- we should make the most sensible/extendible default implementation, but IMO tweeking RequestProcessor functionality should be done with custom code. > 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-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#action_12510506 ] Ryan McKinley commented on SOLR-269: > - conditional copyField, field transformations (between multiple fields > too... something Analyzer can't do), loading certain fields from a database > if missing, >updating a related document, etc. > This all works nicely with a simple 'transform' chain. >> Is the LogUpdateRequestProcessor just an example? > > IMO, it's a default since no logging is done by the > ChangeUpdateRequestProcessor (anyone think of a better name for that?). > Then in a Benchmarking section of the Solr Wiki, we could advise to remove > logging altogether. Or you could remove the ChangeUpdateRequestProcessor to > skip index > changes to better benchmark hotspots in the parsing + doc creation phase, etc. > Isn't logging best configured with standard java.util.logging settings? If necessary, the base processor could check if the logging level is high enough to keep track of somethings. For benchmarking, don't we just want a single noop processor? >> The one compelling chained use case I can think of is for document >> transformation > > Ah, I briefly looked at SOLR-139 when you mentioned it before, but missed the > transformer stuff. > In a way multiple update processors are more generic and wide open... you > could actually insert two documents into the index for each doc added, > you could do transforms on the actual Lucene document (add Field options that > Solr doesn't currently support, etc. > I see what you are getting at, but makes the basic cases more complicated then it needs to be. I have been considering UpdateRequestProcessor as an 'advanced' option where changing their behavior is writing custom code -- not text configuration. In the advanced case where you want to build multiple documents or munge the actual Lucene document existing it may be more difficult to live in a chain rather then have explicit control. If I think the cleanest design would be a single entry point and keeping the real functionality in easily subclassed functions or utility classes. The latest SOLR-139 tries that (but it could still use some cleanup) > 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-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#action_12510504 ] Yonik Seeley commented on SOLR-269: --- Some other issues how to configure processors for multiple update handlers? Perhaps allow configuration of a global default for update handlers with no processors specified? That would make it easy to make sure your custom processor was used everywhere. We should probably have a base class for update handlers to implement initialization logic. > 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-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#action_12510487 ] Yonik Seeley commented on SOLR-269: --- > What do you see as the common use case for wanting to chain request > processors? - conditional copyField, field transformations (between multiple fields too... something Analyzer can't do), loading certain fields from a database if missing, updating a related document, etc. > Is the LogUpdateRequestProcessor just an example? IMO, it's a default since no logging is done by the ChangeUpdateRequestProcessor (anyone think of a better name for that?). Then in a Benchmarking section of the Solr Wiki, we could advise to remove logging altogether. Or you could remove the ChangeUpdateRequestProcessor to skip index changes to better benchmark hotspots in the parsing + doc creation phase, etc. > The one compelling chained use case I can think of is for document > transformation Ah, I briefly looked at SOLR-139 when you mentioned it before, but missed the transformer stuff. In a way multiple update processors are more generic and wide open... you could actually insert two documents into the index for each doc added, you could do transforms on the actual Lucene document (add Field options that Solr doesn't currently support, 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-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.
Re: semantics of RequiredSolrParams.getFieldParam("field","param")
Looking back at SOLR-183 I see JJ had a comment about this...
One open question is getFieldParam: Should the semantics of
required.getFieldParam("facet.limit", "abc") be to fail if the
parameter is not supplied for the field (e.g. f.abc.facet.limit), or
not supplied for either the field or as a general default (e.g.
facet.limit)? In the former case we don't need to override
getFieldParam. I can't think of a reason that one would want to require
explicit field values and disallow
general values, but perhaps someone else could, and a 'field strictness"
flag should be supplied in the RequiredSolrParams constructor.
to which ryan replied...
I don't follow the strict/not strict logic to getFieldParam... If you
don't want strict checking, use the normal SolrParams, if you do, use
RequiredSolrParams
...it seems like there was maybe a missunderstading there about what JJ
was trying to say, ... either that or i'm really confused.
Is there a way to do what I'm trying to do with RequiredSolrParams right
now that i'm just not realizing, or should we add something to achieve
this?
To be honest, at the time I did not understand the semantics of field
params that fall through to the non-field use case.
I imagined you would have handle this case with something like:
String v = params.getFieldParam(f,SolrParams.FACET_DATE_END );
if( v == null ) {
v = required.getParam( SolrParams.FACET_DATE_END );
}
I think it makes sense to change RequiredSolrParams so that you get the
same behavior with:
v = required.getFieldParam( f, SolrParams.FACET_DATE_END );
ryan
[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#action_12510484
]
Ryan McKinley commented on SOLR-269:
I like the AddUpdateCommand changes
What do you see as the common use case for wanting to chain request processors?
Is the LogUpdateRequestProcessor just an example?
The one compelling chained use case I can think of is for document
transformation. In SOLR-139, I toyed with SolrInputDocumentTransformer. The
default case does nothing, and a subclass may use something like:
for( SolrInputDocumentTransformer t : transformers ) {
doc = t.transform( doc );
}
> 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-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.
semantics of RequiredSolrParams.getFieldParam("field","param")
i've run into a weird little oddity while working on SOLR-258 ... the
start/end/gap params need to be required, but i want it to be possible to
use "generaic"values for them even while vaceting over multiple fields,
ie this should work and use the start/end/gap values for both the birth
and death fields...
facet=true&facet.date=birth&facet.date=death&facet.date.start=NOW/YEAR-100YEARS&facet.date.end=NOW/YEAR+1YEAR&facet.date.gap=1YEAR
...but this should cause an error because hte death field doesn't have an
end specified...
facet=true&facet.date=birth&facet.date=death&facet.date.start=NOW/YEAR-100YEARS&f.birth.facet.date.end=NOW/YEAR+1YEAR&facet.date.gap=1YEAR
I'm currently using this...
final SolrParams required = new RequiredSolrParams(params);
...
final String endS = required.getFieldParam(f,SolrParams.FACET_DATE_END);
...but that fails on valid use cases like the first one above, because
getFieldParam delegates to the super which calls
get("f."+f+"."+SolrParams.FACET_DATE_END) .. which triggers this
exception...
org.apache.solr.common.SolrException: Missing required parameter:
f.birth.facet.date.end
at
org.apache.solr.common.params.RequiredSolrParams.get(RequiredSolrParams.java:50)
at
org.apache.solr.common.params.SolrParams.getFieldParam(SolrParams.java:254)
at
org.apache.solr.request.SimpleFacets.getFacetDateCounts(SimpleFacets.java:442)
at
org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:95)
...i considered something like...
final SolrParams required = new RequiredSolrParams(params);
...
final String endS = required.getFieldParam(f,SolrParams.FACET_DATE_END,
params.get(SolrParams.FACET_DATE_END);
..to specify a default value, which would work forthe first use case, but
it wouldn't error in the second use case where neither the generic param
value or the field specific value are specified for a given field.
Looking back at SOLR-183 I see JJ had a comment about this...
> One open question is getFieldParam: Should the semantics of
> required.getFieldParam("facet.limit", "abc") be to fail if the
> parameter is not supplied for the field (e.g. f.abc.facet.limit), or
> not supplied for either the field or as a general default (e.g.
> facet.limit)? In the former case we don't need to override
> getFieldParam. I can't think of a reason that one would want to require
> explicit field values and disallow
> general values, but perhaps someone else could, and a 'field strictness"
> flag should be supplied in the RequiredSolrParams constructor.
to which ryan replied...
>> I don't follow the strict/not strict logic to getFieldParam... If you
>> don't want strict checking, use the normal SolrParams, if you do, use
>> RequiredSolrParams
...it seems like there was maybe a missunderstading there about what JJ
was trying to say, ... either that or i'm really confused.
Is there a way to do what I'm trying to do with RequiredSolrParams right
now that i'm just not realizing, or should we add something to achieve
this?
-Hoss
[jira] Commented: (SOLR-289) Double logging from update handler framework
[
https://issues.apache.org/jira/browse/SOLR-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510482
]
Ryan McKinley commented on SOLR-289:
the "added id={VA902B} in 0ms" is now priinted out in UpdateRequestProcessor -
it has its own Logger, so the detailed output could be configured independently.
or it could be log.fine();
> Double logging from update handler framework
>
>
> Key: SOLR-289
> URL: https://issues.apache.org/jira/browse/SOLR-289
> Project: Solr
> Issue Type: Bug
>Reporter: Yonik Seeley
>Priority: Minor
>
> The update framework in Solr 1.2 causes twice as many log statements to be
> output.
> This will have an adverse performance impact for people adding a single doc
> at a time.
> Example:
> INFO: added id={VA902B} in 0ms
> Jul 5, 2007 1:36:52 PM org.apache.solr.core.SolrCore execute
> INFO: /update 0 0
> Jul 5, 2007 1:36:52 PM org.apache.solr.handler.XmlUpdateRequestHandler update
--
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#action_12510479 ] Yonik Seeley commented on SOLR-269: --- > couldn't that just be a DelegateUpdateRequestProcessor that is constructed > using a list of other UpdateRequestProcessors That might be the way to go if multiple processors were to be very rare... but then you need to come up with a syntax for the args of DelegateUpdateRequestProcessor to specify multiple delegates, and one ends up writing the same code with more complex 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-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] Updated: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-139: -- Attachment: (was: UpdateProcessor.patch) > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Attachments: SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch > > > It would be nice to be able to update some fields on a document without > having to insert the entire document. > Given the way lucene is structured, (for now) one can only modify stored > fields. > While we are at it, we can support incrementing an existing value - I think > this only makes sense for numbers. > for background, see: > http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-139: -- Comment: was deleted > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Attachments: SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch > > > It would be nice to be able to update some fields on a document without > having to insert the entire document. > Given the way lucene is structured, (for now) one can only modify stored > fields. > While we are at it, we can support incrementing an existing value - I think > this only makes sense for numbers. > for background, see: > http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- 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 ] Yonik Seeley updated SOLR-269: -- Attachment: UpdateProcessor.patch OK, this patch adds the ability to specify multiple processor factories. Summary: - decoupled changing the index from logging... I think it makes it much clearer how things work (there was much more logging code than anything else). This also would allow Ryan to add back his incremental timing to a different processor. - added SolrInputDocument to AddUpdateCommand, and added some methods - removed NamedList return from the XML update handler and started passing SolrQueryResponse around instead (this is more future-proof and flexible) - removed adding all the ids to the response... (back to 1.2 response format). We probably shouldn't add ids by default... think of CSV uploading millions of records, etc. - An array of factories is kept, and when a processor is instantiated, it is passed a "next" pointer. An alternative would be to expose a "next factory" pointer to every factory (any advantage to having the current factory call getInstance() on the next factory instead of us doing that?) - untested support for basic syntax to support multiple update processors: org.apache.solr ... > 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-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] Updated: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-139: -- Attachment: UpdateProcessor.patch OK, this patch adds the ability to specify multiple processor factories. Summary: - decoupled changing the index from logging... I think it makes it much clearer how things work (there was much more logging code than anything else). This also would allow Ryan to add back his incremental timing to a different processor. - added SolrInputDocument to AddUpdateCommand, and added some methods - removed NamedList return from the XML update handler and started passing SolrQueryResponse around instead (this is more future-proof and flexible) - removed adding all the ids to the response... (back to 1.2 response format). We probably shouldn't add ids by default... think of CSV uploading millions of records, etc. - An array of factories is kept, and when a processor is instantiated, it is passed a "next" pointer. An alternative would be to expose a "next factory" pointer to every factory (any advantage to having the current factory call getInstance() on the next factory instead of us doing that?) > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Attachments: SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch, > UpdateProcessor.patch > > > It would be nice to be able to update some fields on a document without > having to insert the entire document. > Given the way lucene is structured, (for now) one can only modify stored > fields. > While we are at it, we can support incrementing an existing value - I think > this only makes sense for numbers. > for background, see: > http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-289) Double logging from update handler framework
Double logging from update handler framework
Key: SOLR-289
URL: https://issues.apache.org/jira/browse/SOLR-289
Project: Solr
Issue Type: Bug
Reporter: Yonik Seeley
Priority: Minor
The update framework in Solr 1.2 causes twice as many log statements to be
output.
This will have an adverse performance impact for people adding a single doc at
a time.
Example:
INFO: added id={VA902B} in 0ms
Jul 5, 2007 1:36:52 PM org.apache.solr.core.SolrCore execute
INFO: /update 0 0
Jul 5, 2007 1:36:52 PM org.apache.solr.handler.XmlUpdateRequestHandler update
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: removing most @author tags
FWIW, http://wiki.apache.org/incubator/CodeOfConduct (totally unofficial) discourages them as well, but leaves it up to the PMC... And I recall seeing a Nutch or Hadoop email wanting to remove them as well. On Jul 4, 2007, at 12:00 PM, Bill Au wrote: +1 Bill On 7/2/07, Ian Holsman <[EMAIL PROTECTED]> wrote: Yonik Seeley wrote: > In the spirit of shared ownership, what do people think of getting rid > of @author tags (for committers or other dev people that consent?). > Other apache projects have done so, for a host of reasons. > > - some people don't use author tags, hence credit is uneven > - author tags tend to only credit the original author, and not > everyone that works on the code after (or does code reviews, lends > ideas, etc, etc) > - we have CHANGES.txt to generally credit people (and it prob does a > better job) you forgot another big reason people tend to email people in the @author tags directly, instead of using the lists.
[jira] Updated: (SOLR-60) Remove overwritePending, overwriteCommitted flags?
[ https://issues.apache.org/jira/browse/SOLR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-60: -- Attachment: SOLR-60-Overwrite.patch This changes AddUpdateCommand to want 'update' and depricates the other flags public boolean overwrite = true; @Deprecated public Boolean allowDups; @Deprecated public Boolean overwritePending; @Deprecated public Boolean overwriteCommitted; If any of allowDups, overwritePending, overwriteCommitted are set, it will use old style calculations. Autoboxing should handle the conversion cleanly. > Remove overwritePending, overwriteCommitted flags? > -- > > Key: SOLR-60 > URL: https://issues.apache.org/jira/browse/SOLR-60 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Yonik Seeley >Priority: Minor > Attachments: SOLR-60-Overwrite.patch > > > The overwritePending, overwriteCommitted, allowDups flags seem needlessly > complex and don't add much value. Do people need/use separate control over > pending vs committed documents? > Perhaps all most people need is overwrite=true/false? > overwritePending, overwriteCommitted were originally added because it was a > (mis)feature that another internal search tool had. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-269) UpdateRequestProcessorFactory - process requests before submitting them
FYI, I'm working up a prototype right now to handle multiple request processors. excellent. check: https://issues.apache.org/jira/browse/SOLR-139 to see how I was thinking about supporting multiple processors. Essentially a single parent processor that may loop through 'transformers' or whatever in the custom case. (not that I think my design is *the* answer) ryan
Re: bug in XppUpdateHandler?
On 5-Jul-07, at 10:44 AM, Ryan McKinley wrote: Yonik Seeley wrote: On 7/5/07, Ryan McKinley <[EMAIL PROTECTED]> wrote: > > If I get a chance I'll take a look to see what the problem is, but I > haven't touched this section of the code in quite a while. > I'm looking at it now... I'll at least add a test that fails for the Stax version and passes Xpp. You probably need to clear the indexedId between multiple adds. yup. fixed in r553574 Thanks Ryan. -Mike
[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#action_12510429 ] Hoss Man commented on SOLR-269: --- couldn't that just be a DelegateUpdateRequestProcessor that is constructed using a list of other UpdateRequestProcessors? :) > 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-UpdateRequestProcessorFactory.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#action_12510425 ] Yonik Seeley commented on SOLR-269: --- FYI, I'm working up a prototype right now to handle multiple request processors. > 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-UpdateRequestProcessorFactory.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.
Re: bug in XppUpdateHandler?
Yonik Seeley wrote: On 7/5/07, Ryan McKinley <[EMAIL PROTECTED]> wrote: > > If I get a chance I'll take a look to see what the problem is, but I > haven't touched this section of the code in quite a while. > I'm looking at it now... I'll at least add a test that fails for the Stax version and passes Xpp. You probably need to clear the indexedId between multiple adds. yup. fixed in r553574
[jira] Created: (SOLR-288) Allow custom IndexSearcher class
Allow custom IndexSearcher class Key: SOLR-288 URL: https://issues.apache.org/jira/browse/SOLR-288 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.2 Environment: all Reporter: Jerome Eteve Priority: Minor Fix For: 1.2 Allows specification of the used IndexSearcher class in the schema like this: I got a patch for this for the src of version 1.2.0 , but I dont know if I can post it here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: bug in XppUpdateHandler?
On 7/5/07, Ryan McKinley <[EMAIL PROTECTED]> wrote: > > If I get a chance I'll take a look to see what the problem is, but I > haven't touched this section of the code in quite a while. > I'm looking at it now... I'll at least add a test that fails for the Stax version and passes Xpp. You probably need to clear the indexedId between multiple adds. -Yonik
Re: bug in XppUpdateHandler?
If I get a chance I'll take a look to see what the problem is, but I haven't touched this section of the code in quite a while. I'm looking at it now... I'll at least add a test that fails for the Stax version and passes Xpp. ryan
Hudson build is back to normal: Solr-Nightly #133
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/133/changes
