0

I am facing a weird(might not be weird for experienced people) issue where ContentSearch API is returning null value for few fields while I can see the correct values in Solr. The fields whose values are returning as null are of String type because of Sitecore field type as Droplist and Treelist. Wondering if there is anything obvious I am missing somewhere?

Search Result Class:

public class BlogSearchModel 
{
    //Blog Specific
    [IndexField("title_t")]
    public string Title { get; set; }
    [IndexField("excerpt_t")]
    public string Excerpt { get; set; }
    [IndexField("body_t")]
    public string Body { get; set; }

    [IndexField("author_s")]
    public string Author { get; set; }

    [IndexField("category_s")]
    public string Category { get; set; }
    [IndexField("tags_sm")]
    public IEnumerable<string> TagID { get; set; }
}

Here Author, Category, TagID whose value is returning as Null have inherited templates.

The solr log shows the query as:

Solr Query - ?q=((site_sm:("xxxxx") AND _templates:("795b38b1aca6433fb5f1e02ee350857d")) AND (body_t:(*blog1*) OR title_t:(*blog1*) OR excerpt_t:(*blog1*))) AND _val_:__boost&start=0&rows=1000000&fl=tags,_templates,author_t,_fullpath,_name,__created_by_s,title_t,_template,site_sm,category_t,excerpt_t,_language,body_t,itemurl_t,_uniqueid,_datasource&fq=_indexname:(sitecore_master_index)&wt=xml

2
  • What is the search result item class code? Aug 4 at 13:15
  • thanks, @MarekMusielak. I have updated the question with the class definition. Aug 4 at 13:21
2

You don't need the suffix in the IndexField attribute here. The Sitecore Content Search API will (most of the time) add that in when it builds the search query. So it's probably doubling those up, you would see that in your search logs.

Build your model class like this:

public class BlogSearchModel 
{
    //Blog Specific
    [IndexField("title")]
    public string Title { get; set; }
    [IndexField("excerpt")]
    public string Excerpt { get; set; }
    [IndexField("body")]
    public string Body { get; set; }

    [IndexField("author")]
    public string Author { get; set; }

    [IndexField("category")]
    public string Category { get; set; }
    [IndexField("tags")]
    public IEnumerable<string> TagID { get; set; }
}
3
  • I did the changes in my model as per your suggestion without any luck. I am wondering if I am missing anything else.. Aug 4 at 17:41
  • I have updated the question with the query showing in the Solr log. It indeed seems that fields returned in the result are not exactly the same as showing in solr result. Aug 4 at 17:51
  • If you go to solr dashborad and in query part just search with template, do you see category and tagid there in search results? Aug 5 at 15:21
2

What version of Sitecore are you on?

I've got the same problem with Sitecore 10.1 with a droplist field. It converts the fieldname to <fieldname>_t when querying instead of <fieldname>_s, even though the config is correct. It's not a calculated field, just a standard dynamic field.

Take a look at your search log output - you can see sitecore thinks your Author field is called author_t which is just wrong, because in the config we have this which clearly defines a droplist to be a string and thus it is stored as author_s in Solr:

<fieldTypes hint="raw:AddFieldByFieldTypeName">
    ...
    <fieldType fieldTypeName="icon|droplist|grouped droplist" returnType="string" />
    ...
</fieldTypes>

I believe this to be a bug in Sitecore when it's trying to determine the Solr type of your strongly-typed C# String property. The docs state that it tries to work out which solr type to use from the config typeMatches which will result in 3 matched types as follows:

<typeMatch typeName="lowercaseString" type="System.String" fieldNameFormat="{0}_ls" ... />
<typeMatch typeName="string" type="System.String" fieldNameFormat="{0}_s" ... />
<typeMatch typeName="text" type="System.String" fieldNameFormat="{0}_t"... />

It should then query solr to work out which of these 3 match your field author and then use that type for the query. However I can't see any logs of it querying solr. In the absence of any more info I assume there is a bug and it's just picking whichever type it wants / whichever is first in the array.

The "solution" (ugly workaround) is to define the specific droplist field in the DefaultSolrIndexConfiguration like so:

    <configuration>
      <sitecore>
        <contentSearch>
          <indexConfigurations>
            <defaultSolrIndexConfiguration>
                <fieldNames hint="raw:AddFieldByFieldName">
                  <field fieldName="<your-droplist-field-name>" returnType="string" />
                </fieldNames>
                </defaultSolrIndexConfiguration>
            </indexConfigurations>
            </contentSearch>
        </sitecore>
    </configuration>

The key part is telling it that your specific field needs to be treated as string, not text.

It's hacky and I don't like it because it only works for single instances, but it's what I've used until I can find a proper fix.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.