SearchQuery fields property ArgumentNullException and Fragments result always null

.NET SDK
1

I have the following Searchquery (using CouchbaseNetClient v2.3.9)

SearchQuery fc = new SearchQuery();
fc.Index = “beer-ft”;
fc.Highlighting(HighLightStyle.Html);
fc.Fields(“name”, “style”);
fc.Query = new MatchQuery(“american”);
fc.SearchParams = new SearchParams().Limit(10);

When I run the application I get ArgumentNulException with the message must be non-null and have at least one value.
Parameter name: fields. As you can see above I am passing the value as expected for the Fields method.

Second issue having commented out the fields method I get the results back however the SearchQueryRow Fragments property is null i expected the result to be the same as from the couchbase interface

2

@vinster -

This looks suspiciously bug-like. Can you post your index definition and we’ll try to replicate?

Thanks,

Jeff

3

Jeff excuse my ignorance I am new to couchbase I am hoping the following information is what you are after if not could you please elaborate as to how I can get you the info

Pasted image1150×732 80.5 KB

4

@vinster -

No problem, click the “Show index definition JSON” checkbox.

-Jeff

5

Doh sorry that is a bit embarrassing :slight_smile: here you go

{
“type”: “fulltext-index”,
“name”: “beer-ft”,
“uuid”: “5a40b26b5f278375”,
“sourceType”: “couchbase”,
“sourceName”: “beer-sample”,
“sourceUUID”: “a05591fe4723f700a97705d453f5a3ea”,
“planParams”: {
“maxPartitionsPerPIndex”: 32,
“numReplicas”: 0,
“hierarchyRules”: null,
“nodePlanParams”: null,
“pindexWeights”: null,
“planFrozen”: false
},
“params”: {
“mapping”: {
“byte_array_converter”: “json”,
“default_analyzer”: “standard”,
“default_datetime_parser”: “dateTimeOptional”,
“default_field”: “_all”,
“default_mapping”: {
“display_order”: “1”,
“dynamic”: false,
“enabled”: false,
“properties”: {
“name”: {
“dynamic”: false,
“enabled”: true,
“fields”: [
{
“analyzer”: “”,
“display_order”: “1”,
“include_in_all”: true,
“include_term_vectors”: true,
“index”: true,
“name”: “name”,
“store”: true,
“type”: “text”
}
]
},
“style”: {
“dynamic”: false,
“enabled”: true,
“fields”: [
{
“analyzer”: “”,
“display_order”: “0”,
“include_in_all”: true,
“include_term_vectors”: true,
“index”: true,
“name”: “style”,
“store”: true,
“type”: “text”
}
]
}
}
},
“default_type”: “_default”,
“index_dynamic”: true,
“store_dynamic”: false,
“type_field”: “type”,
“types”: {
“beer”: {
“display_order”: “0”,
“dynamic”: true,
“enabled”: true,
“properties”: {
“name”: {
“dynamic”: false,
“enabled”: true,
“fields”: [
{
“analyzer”: “”,
“display_order”: “1”,
“include_in_all”: true,
“include_term_vectors”: true,
“index”: true,
“name”: “name”,
“store”: true,
“type”: “text”
}
]
},
“style”: {
“dynamic”: false,
“enabled”: true,
“fields”: [
{
“analyzer”: “”,
“display_order”: “0”,
“include_in_all”: true,
“include_term_vectors”: true,
“index”: true,
“name”: “style”,
“store”: true,
“type”: “text”
}
]
}
}
}
}
},
“store”: {
“kvStoreName”: “forestdb”
}
},
“sourceParams”: {
“clusterManagerBackoffFactor”: 0,
“clusterManagerSleepInitMS”: 0,
“clusterManagerSleepMaxMS”: 2000,
“dataManagerBackoffFactor”: 0,
“dataManagerSleepInitMS”: 0,
“dataManagerSleepMaxMS”: 2000,
“feedBufferAckThreshold”: 0,
“feedBufferSizeBytes”: 0
}
}

6

Jeff have you been able to replicate this issue? If so any idea on when a fix will be released?

7

@vinster -

It looks like you found a bug, here is the ticket: Loading...

A fix is planned for 2.3.10 to be released early next month.

-Jeff