[
https://issues.apache.org/jira/browse/SOLR-12888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733157#comment-16733157
]
David Smiley commented on SOLR-12888:
-------------------------------------
I kinda like it as an URP so I left it as-such. Even Solr internal things are
URPs (think distributed search, logging, RunUpdate, and many opt-in features)
-- it didn't have to be this way but it is and it's fine. And I think it's
nicer to fit code into an overarching framework than add more logic into other
code that already has complexities to deal with. And by doing this in an URP,
we avoid a thread safety bug -- DistributedUpdateProcessor's has logic to
examine remaining URPs and see when to clone the document or not. We do indeed
need to clone the doc when this logic is in place, and now it will do so.
I could have hard-coded in the reference to this URP in
RunUpdateProcessorFactory's constructor (similar to how TRA does so in
DistributedUpdateProcessorFactory) but I chose to instead make it potentially
configurable using an internal automatically registered update chain named
{{\_preRun\_}}. To make this work I wanted to be able to create an URP chain
while specifying the "last" (next) URP, so I did this, which was pretty easy.
I noticed that
{{org.apache.solr.update.processor.UpdateRequestProcessorChain#createProcessor}}
had surprising logic about a factory's getInstance method returning null. I
think that's silly since we pass in a "last" (next) argument and so a factory
that choses to do nothing should, IMO, return that argument instead of
returning null. This avoid special casing logic and thus simplified
createProcessor's logic. I changed a couple URPs in Solr that do this to this
approach.
I mentioned this issue at the committer's meeting at Activate; I think
[~yo...@apache.org] and [~hossman] had comments then. [~moshebla] maybe you
want to review.
> NestedUpdateProcessor code should activate automatically in 8.0
> ---------------------------------------------------------------
>
> Key: SOLR-12888
> URL: https://issues.apache.org/jira/browse/SOLR-12888
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Blocker
> Fix For: master (8.0)
>
> Attachments: SOLR-12888.patch
>
>
> If the schema supports it, the NestedUpdateProcessor URP should be registered
> automatically somehow. The Factory for this already looks for the existence
> of certain special fields in the schema, so that's good. But the URP Factory
> needs to be added to your chain in any of the ways we support that. _In 8.0
> the user shouldn't have to do anything to their solrconfig._
> We might un-URP this and call directly somewhere. Or perhaps we might add a
> special named URP chain (needn't document), defined automatically, that
> activates at RunURP. Perhaps other things could be added to this in the
> future.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
