Proposed Additional Hooks in SolrEventListener

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposed Additional Hooks in SolrEventListener

Kevin Jia

Hi Everyone,


I'm looking to add Prospective Search functionality to Solr, similar to what Luwak (https://github.com/flaxsearch/luwak) does - see existing JIRA ticket : https://issues.apache.org/jira/browse/SOLR-4587. To do this I need to maintain an in-memory cache that is in sync with the document index (custom cache that is not a straightforwards field cache). 

To maintain my in-memory cache, I wanted to add functionality after updates (in DirectUpdateHandler2) and SolrCore instantiation. Instead of changing the code directly I wanted to add more hooks to SolrEventListener, namely these: 


public void postCoreConstruct(SolrCore core);
public void preAddDoc(AddUpdateCommand cmd);
public void postAddDoc(AddUpdateCommand cmd);
public void preDelete(DeleteUpdateCommand cmd);
public void postDelete(DeleteUpdateCommand cmd);


I also made a ticket: https://issues.apache.org/jira/browse/SOLR-4587. If anyone ever needs similar custom behavior, they would be able to use these hooks as well. 

Does anyone have any thoughts or suggestions on my proposed changes? Is there a better way to do this? If not, I can submit a patch soon. 


Best,

Kevin


Reply | Threaded
Open this post in threaded view
|

Re: Proposed Additional Hooks in SolrEventListener

Kevin Jia

bounce


From: Kevin Jia
Sent: December 12, 2018 6:36:33 PM
To: [hidden email]
Subject: Proposed Additional Hooks in SolrEventListener
 

Hi Everyone,


I'm looking to add Prospective Search functionality to Solr, similar to what Luwak (https://github.com/flaxsearch/luwak) does - see existing JIRA ticket : https://issues.apache.org/jira/browse/SOLR-4587. To do this I need to maintain an in-memory cache that is in sync with the document index (custom cache that is not a straightforwards field cache). 

To maintain my in-memory cache, I wanted to add functionality after updates (in DirectUpdateHandler2) and SolrCore instantiation. Instead of changing the code directly I wanted to add more hooks to SolrEventListener, namely these: 


public void postCoreConstruct(SolrCore core);
public void preAddDoc(AddUpdateCommand cmd);
public void postAddDoc(AddUpdateCommand cmd);
public void preDelete(DeleteUpdateCommand cmd);
public void postDelete(DeleteUpdateCommand cmd);


I also made a ticket: https://issues.apache.org/jira/browse/SOLR-4587. If anyone ever needs similar custom behavior, they would be able to use these hooks as well. 

Does anyone have any thoughts or suggestions on my proposed changes? Is there a better way to do this? If not, I can submit a patch soon. 


Best,

Kevin


Reply | Threaded
Open this post in threaded view
|

Re: Proposed Additional Hooks in SolrEventListener

Tomás Fernández Löbbe
Hi Kevin,
Isn't UpdateRequestProcessor enough for what you need?

On Tue, Dec 18, 2018 at 1:29 PM Kevin Jia <[hidden email]> wrote:

bounce


From: Kevin Jia
Sent: December 12, 2018 6:36:33 PM
To: [hidden email]
Subject: Proposed Additional Hooks in SolrEventListener
 

Hi Everyone,


I'm looking to add Prospective Search functionality to Solr, similar to what Luwak (https://github.com/flaxsearch/luwak) does - see existing JIRA ticket : https://issues.apache.org/jira/browse/SOLR-4587. To do this I need to maintain an in-memory cache that is in sync with the document index (custom cache that is not a straightforwards field cache). 

To maintain my in-memory cache, I wanted to add functionality after updates (in DirectUpdateHandler2) and SolrCore instantiation. Instead of changing the code directly I wanted to add more hooks to SolrEventListener, namely these: 


public void postCoreConstruct(SolrCore core);
public void preAddDoc(AddUpdateCommand cmd);
public void postAddDoc(AddUpdateCommand cmd);
public void preDelete(DeleteUpdateCommand cmd);
public void postDelete(DeleteUpdateCommand cmd);


I also made a ticket: https://issues.apache.org/jira/browse/SOLR-4587. If anyone ever needs similar custom behavior, they would be able to use these hooks as well. 

Does anyone have any thoughts or suggestions on my proposed changes? Is there a better way to do this? If not, I can submit a patch soon. 


Best,

Kevin