Re: Model type does not exist MultipleAdditiveTreesModel

[Kamuela Lau]

Hi Roee,

I think that in addition to the fact that the feature param is blank in the
model JSON, you should also make sure that the features you put in the JSON
have been added to the feature-store.
This generic error also occurs when the features haven't been added to the
feature store.

In addition, for Multiple Additive Trees Model, you should also make sure
you have quotes around the values, as shown here:
https://lucene.apache.org/solr/7_3_1/solr-ltr/org/apache/solr/ltr/model/MultipleAdditiveTreesModel.html

If you do not add quotes, the same 'Model type does not exist' error will
occur.

Hope this helps!

On Sat, Apr 6, 2019 at 1:03 AM Kamal Kishore Aggarwal 
wrote:

> Hi Roee,
>
> It looks the error is due to blank feature param value in the json.
>
> "name" : "my",
>"features":[],
>"params" : {
>
> I have observed that many a times solr ltr returns generic error that
> 'Model
> type does not
> exist', but later actually found to be an issue with json. Just wanted to
> share my experience.
>
> Regards
> Kamal
>
> On Thu, May 31, 2018 at 4:07 PM Roee T  wrote:
>
> > Hi all,
> > I'm trying to upload the most simple model to solr 7.3.1 and i get an
> > error:
> >
> > the model:
> >
> > {
> >"class" : "org.apache.solr.ltr.model.MultipleAdditiveTreesModel",
> >"name" : "my",
> >"features":[],
> >"params" : {
> >"trees" : [
> >{
> >"weight" : 1,
> >"root" : {
> >"value" : -10
> >}} ]}}
> >
> > The error:
> >   "error":{
> > "metadata":[
> >   "error-class","org.apache.solr.common.SolrException",
> >   "root-error-class","java.lang.IllegalArgumentException"],
> > "msg":"org.apache.solr.ltr.model.ModelException: Model type does not
> > exist org.apache.solr.ltr.model.MultipleAdditiveTreesModel",
> > "code":400}}
> >
> >
> > I inserted the configurations to solrconfig.xml like
> >> regex=".*\.jar" />
> > and started solr using   -Dsolr.ltr.enabled=true
> >
> > please help me
> > Thanks you all ;)
> >
> >
> >
> > --
> > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
> >
>

Performance problems with extremely common terms in collection (Solr 7.4)

[Ash Ramesh]

Hi everybody,

We have a corpus of 50+ million documents in our collection. I've noticed
that some queries with specific keywords tend to be extremely slow. E.g.
the q=`photography' or q='background'. After digging into the raw
documents, I could see that these two terms appear in greater than 90% of
all documents, which means solr has to score each of those documents.

Is there a best practise to deal with these sort of queries? Should solr be
able to handle these queries normally quickly (we have 8 shards). The
average, reproducible time for the response on these queries is between
1.5-2.5 seconds.

Please let me know if more information is required.

Regards.

Ash

-- 
*P.S. We've launched a new blog to share the latest ideas and case studies 
from our team. Check it out here: product.canva.com 
. ***
** Empowering the 
world to design
Also, we're hiring. Apply here! 

  
  
    
  

Solr spellcheck Collation JSON

[Moyer, Brett]

Hello,

Looks like a more recent Solr release introduced a bug for collation. 
Does anyone know of a way to correct it, or if a future release will address? 
Because of this change we had to make the app teams rewrite their code. Made us 
look bad because we can't control our code and introduced a bug their 
perspective) Thanks

Solr 7.4
--
"spellcheck": {
"suggestions": [
"acount",
{
"numFound": 1,
"startOffset": 0,
"endOffset": 6,
"suggestion": [
"account"
]
}
],
"collations": [
"collation", <-this is the bad line
"account"
]

Previous Solr versions
--
"spellcheck": {
"suggestions": [
"acount",
{
"numFound": 1,
"startOffset": 0,
"endOffset": 6,
"suggestion": [
"account"
]
}
],
"collations": [
"collation":"account" <--correct format
]

Brett Moyer
*
This e-mail may contain confidential or privileged information.
If you are not the intended recipient, please notify the sender immediately and 
then delete it.

TIAA
*

Re: solr tika extraction video creation date problem (hours ahead)

[Where is Where]

Thank you very much Alex for the great suggestion.

On Fri, Apr 5, 2019 at 7:25 PM Alexandre Rafalovitch 
wrote:

> Well, Tika would use different libraries to extract different formats.
> So maybe there is a bug. I would just get a standalone tika (of
> matching version to the one in Solr) and see what the output from two
> sample files are. Then, I would check with the latest Tika, just in
> case.
>
> I would also use some non-Tika way to check what the dates are, just
> in case the date is wrong during encoding rather than during indexing.
> A low-probability chance, but just covering all the bases.
>
> Regards,
>Alex.
>
> On Fri, 5 Apr 2019 at 01:39, whisere  wrote:
> >
> > Thanks Alex. The problem is image creation date is correct, but the video
> > creation date is wrong (hours behind), if I set the time_zone I think the
> > image creation date will be wrong then. wonder what the difference
> between
> > image and video extraction in tika.
> >
> >
> >
> > --
> > Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>