0

I have two indexes, index1 is the old and currently used index and the new index2 contains additionally a new string array field myArray1.

Azure Search is using documentdb collection as a source and myArray1 is filled out properly there. However when querying the document in the Azure Search Explorer myArray1 is always empty. The search explorer is set to index2. I also tried resetting index2 but without luck.

I am using a CreateDataSource.json to define the query for the documentdb collection. In this query I am selecting the prop myArray1.

Any idea why the index is not picking up the values stored in myArray?

Here is the data source query: 

SELECT c.id AS Id, c.crew AS Crews, c['cast'] AS Casts FROM c WHERE c._ts >= @HighWaterMark

If I run it against documentdb in Azure search it works fine.

Here is the index definition:

Index definition = new Index()
{
     Name = "index-docdb4",
     Fields = new[]
     {
           new Field("Id", DataType.String, AnalyzerName.StandardLucene) { IsKey = true, IsFilterable = true },
           new Field("Crews", DataType.Collection(DataType.String)) { IsFilterable = true },
           new Field("Casts", DataType.Collection(DataType.String)) { IsFilterable = true }
                }                
            };

Here is the indexer json file

{
  "name": "indexer-docdb4",
  "dataSourceName": "datasource-docdb",
  "targetIndexName": "index-docdb4",
  "schedule": {
    "interval": "PT5M",
    "startTime": "2015-01-01T00:00:00Z"
  }
}

Here is a documentdb example file

{
    "id": "300627",        
    "title": "Carmen",
    "originalTitle": "Carmen",
    "year": 2011,        
    "genres": [
      "Music"
    ],        
    "partitionKey": 7,
    "_rid": "OsZtAIcaugECAAAAAAAAAA==",
    "_self": "dbs/OsZtAA==/colls/OsZtAIcaugE=/docs/OsZtAIcaugECAAAAAAAAAA==/",
    "_etag": "\"0400d17e-0000-0000-0000-590a493a0000\"",
    "_attachments": "attachments/",
    "cast": [
      "315986",
      "321880",
      "603325",
      "484671",
      "603324",
      "734554",
      "734555",
      "706818",
      "711766",
      "734556",
      "734455"
    ],
    "crew": [
      "58185",
      "390726",
      "302640",
      "670953",
      "28046",
      "122587"
    ],
    "_ts": 1493846327
  },
doorman
  • 15,707
  • 22
  • 80
  • 145
  • What library are you using to call Azure Search? The official Azure Search .NET SDK does not have a method called ReplaceDocumentAsync. – Bruce Johnston May 02 '17 at 21:35
  • Hi @BruceJohnston sorry about that, please see the updated question – doorman May 02 '17 at 22:43
  • Can you share your data source query and indexer definition? Also, can you confirm whether other fields are being populated correctly? – Bruce Johnston May 03 '17 at 00:39
  • Hi @BruceJohnston thanks for your help please see the updated question. And yes other fields are populated fine. I also have a genre field which is working but the casts and crews fields are new. – doorman May 03 '17 at 09:53
  • Can you share your *indexer* definition as well? In particular, it would be helpful to see if you're using any field mappings. Also, have you checked the status of your indexer executions? Are there any errors? – Bruce Johnston May 03 '17 at 19:00
  • Also, this is unrelated to your question, but why are you using the standard Lucene analyzer on your Id field? Will users really be doing full-text searches for IDs? – Bruce Johnston May 03 '17 at 19:01
  • It would also help if you share an example document from your Document DB collection. – Bruce Johnston May 03 '17 at 19:22
  • Hi @BruceJohnston thanks for your help. Please see the updated question. Regarding the lucene analyzer it was a mistake. I will check if I get errors on the indexer exceution. – doorman May 03 '17 at 22:11
  • After creating the index I get a Index 'index-docdb4' does not exist but after a while the index starts to build up. But the casts and crews props are still empy. – doorman May 03 '17 at 22:17
  • I'm not that familiar with Document DB, but can you explain why the SELECT clause treats cast and crew differently (i.e. -- c['cast'] versus c.crew)? I'm not sure if this is the problem or not, but it's the only thing I see that doesn't seem right. – Bruce Johnston May 04 '17 at 17:07

0 Answers0