[jira] [Commented] (SOLR-11250) Add new LTR model which loads the model definition from the external resource

["Yuki Yano (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-11250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239005#comment-16239005 ] 

Yuki Yano commented on SOLR-11250:
----------------------------------

Hi [~cpoerschke],

Thank you for revising the patch!

bq. In the TestWrapperModel class the WrapperModel equals and hashCode methods previously had been excluded from the "this method must be overridden" check but I struggled to justify that exclusion to myself and so added overridden WrapperModel equals and hashCode methods. What do you think? We could go back to "not overridden" and add the reason (which i could not find) re: why the methods must not be overridden.

Actually, both are OK for me. I follow your decision.
I didn't add overridden {{equals}} and {{hashCode}} because I thought wrapper model should be same as wrapped model due to its behavior (or, maybe, I just followed the way of other {{Model}} classes).

bq. Following on from that I wondered, is there a use case where model name and/or feature store name could usefully be different between the wrapper model and the wrapped model?

I think feature store name cannot be different because wrapper model doesn't use own feature store for scoring. Thus, I agree with your modification.

On the other hand, I think name could be different because the name of wrapper model can be used as the alias of the wrapped model. With the example of {{largeExternallyStoredModel.json}}, if we fix the name of wrapper model (like "prodModel"), users can always use same rerankModel (i.e, "prodModel") even if the version of wrapped model was changed (like "20171103" to "20171206"). I think this feature is useful because we can avoid the influence of updating models to users (in other words, we can develop front-end and back-end separately).


> Add new LTR model which loads the model definition from the external resource
> -----------------------------------------------------------------------------
>
>                 Key: SOLR-11250
>                 URL: https://issues.apache.org/jira/browse/SOLR-11250
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: contrib - LTR
>            Reporter: Yuki Yano
>            Assignee: Christine Poerschke
>            Priority: Minor
>         Attachments: SOLR-11250.patch, SOLR-11250.patch, SOLR-11250.patch, SOLR-11250_master.patch, SOLR-11250_master_v2.patch, SOLR-11250_master_v3.patch, SOLR-11250_master_v4.patch
>
>
> We add new model which contains only the location of the external model and loads it during the initialization.
> By this procedure, large models which are difficult to upload to ZooKeeper can be available.
> The new model works as the wrapper of existing models, and deligates APIs to them.
> We add two classes by this patch:
> * {{ExternalModel}} : a base class for models with external resources.
> * {{URIExternalModel}} : an implementation of {{ExternalModel}} which loads the external model from specified URI (ex. file:, http:, etc.).
> For example, if you have a model on the local disk "file:///var/models/myModel.json", the definition of {{URIExternalModel}} will be like the following.
> {code}
> {
>   "class" : "org.apache.solr.ltr.model.URIExternalModel",
>   "name" : "myURIExternalModel",
>   "features" : [],
>   "params" : {
>     "uri" : "file:///var/models/myModel.json"
>   }
> }
> {code}
> If you use LTR with {{model=myURIExternalModel}}, the model of {{myModel.json}} will be used for scoring documents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org