[
https://issues.apache.org/jira/browse/SOLR-11250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-11250:
---------------------------------------
Attachment: SOLR-11250.patch
Hello [~yuyano],
This week I finally managed to return to this ticket, sorry for the delay.
The attached patch is rebased against the latest master branch including the
SOLR-11603 removal of the LTRScoringModel.hasParams() method. I've also
tinkered a little with test code e.g. in TestWrapperModel the
testOverwrittenMethods and testDelegateMethods are now linked to ensure good
coverage if new methods are added in future and there are small
TestWrapperModel.createMockWrappedModel and
TestModelManagerPersistence.doWrapperModelPersistenceChecks helper methods
factored out to reduce code duplication.
There's also two functional changes I'd value your opinion on:
* 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.
* Again in the TestWrapperModel class, the fact that the getName method was
excluded from the "this method must be overridden" check caught my attention.
The getName method being excluded from the check but the getFeatureStoreName
method not being excluded. 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?
** The wrapper model itself has no features and so requiring that the wrapper
model and the wrapped model configure the same feature store name seems
unproblematic from a technical perspective and might help avoid user error e.g.
updating the wrapper model feature store name when the wrapped model feature
store name should have been updated instead. What do you think?
** The wrapped model name being different from the wrapper model name, that is
less clear-cut I think. The wrapped model could perhaps be called
{{largeModelDefinition20171103}} and be stored in
{{largeExternallyStoredModel.json}} file and the wrapper model could be called
{{largeExternallyStoredModel}} and over time the
{{largeExternallyStoredModel.json}} file content could change e.g. to a
different {{largeModelDefinition20171206}} model name. On the other hand,
having two different model names raises the question of which name is which and
specifically which of the two names should be used in the {{rq=\{!ltr
rerankModel=...}} parameter. For the purposes of the {{rq}} parameter the
applicable model name is of course that of the wrapper model and the model name
of the wrapped model is actually not of interest to anyone. What do you think?
** The revised patch validates that model name and feature store name match.
This adds a little code complexity and also required small changes to the tests.
> 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: [email protected]
For additional commands, e-mail: [email protected]
