[ https://issues.apache.org/jira/browse/SOLR-12955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16675378#comment-16675378 ]
Amrit Sarkar edited comment on SOLR-12955 at 11/5/18 4:11 PM: -------------------------------------------------------------- Thanks [~brot] for looking into refactoring DUP. Now with CdcrURP; I am working on SOLR-12057 to deprecate CdcrURP altogether as it doesn't serve any strong purpose and eventually plans to phase out in potentially 8.0 or later. A single protected method is required to be extended in CdcrURP from DURP i.e. {{filterParams(SolrParams..)}}. I am attaching the potential code for CdcrURP for reference: {code} /** * <p> * Extends {@link org.apache.solr.update.processor.DistributedUpdateProcessor}, * and attach the _version_ from the update to the doc, * for synchronizing checkpoints b/w clusters. * This URP to be added at target cluster in uni-directional * and all clusters involved in bi-directional sync. * </p> */ public class CdcrUpdateProcessor extends DistributedUpdateProcessor { public static final String CDCR_UPDATE = "cdcr.update"; public CdcrUpdateProcessor(SolrQueryRequest req, SolrQueryResponse rsp, UpdateRequestProcessor next) { super(req, rsp, next); } /** * <p> * Method to check if cdcr forwarded update. * If yes, attach the _version_ from the update to the doc, * for synchronizing checkpoint b/w clusters * </p> */ protected ModifiableSolrParams filterParams(SolrParams params) { ModifiableSolrParams result = super.filterParams(params); if (params.get(CDCR_UPDATE) != null) { result.set(CDCR_UPDATE, ""); result.set(CommonParams.VERSION_FIELD, params.get(CommonParams.VERSION_FIELD)); } return result; } } {code} So whichever class out of the two has the protected {{filterParams(...)}}, we need to extend the CdcrURP with that particular class. The patch for SOLR-12057 is almost ready and waiting for final review. Hope this helps. was (Author: sarkaramr...@gmail.com): Thanks [~brot] for looking into refactoring DUP. Now as far as with CdcrURP; I am working on SOLR-12057 to deprecate CdcrURP altogether as it doesn't serve any strong purpose and eventually plans to phase out in potentially 8.0 or later. A single protected method is required to be extended in CdcrURP from DURP i.e. {{filterParams(SolrParams..)}}. I am attaching the potential code for CdcrURP for reference: {code} /** * <p> * Extends {@link org.apache.solr.update.processor.DistributedUpdateProcessor}, * and attach the _version_ from the update to the doc, * for synchronizing checkpoints b/w clusters. * This URP to be added at target cluster in uni-directional * and all clusters involved in bi-directional sync. * </p> */ public class CdcrUpdateProcessor extends DistributedUpdateProcessor { public static final String CDCR_UPDATE = "cdcr.update"; public CdcrUpdateProcessor(SolrQueryRequest req, SolrQueryResponse rsp, UpdateRequestProcessor next) { super(req, rsp, next); } /** * <p> * Method to check if cdcr forwarded update. * If yes, attach the _version_ from the update to the doc, * for synchronizing checkpoint b/w clusters * </p> */ protected ModifiableSolrParams filterParams(SolrParams params) { ModifiableSolrParams result = super.filterParams(params); if (params.get(CDCR_UPDATE) != null) { result.set(CDCR_UPDATE, ""); result.set(CommonParams.VERSION_FIELD, params.get(CommonParams.VERSION_FIELD)); } return result; } } {code} So whichever class out of the two has the protected {{filterParams(...)}}, we need to extend the CdcrURP with that particular class. The patch for SOLR-12057 is almost ready and waiting for final review. Hope this helps. > Refactor DistributedUpdateProcessor > ----------------------------------- > > Key: SOLR-12955 > URL: https://issues.apache.org/jira/browse/SOLR-12955 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Bar Rotstein > Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Lately As I was skimming through Solr's code base I noticed that > DistributedUpdateProcessor has a lot of nested if else statements, which > hampers code readability. -- 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