Modeling data to be used in DocumentDB and Azure Search

Question

This is a followup question to another question I had - Benefits of using Document DB after connecting with Azure Search

Storing your data in DocumentDB and integrating with Azure Search requires you to model your data twice - once for the document in DocDB and another for the search entity in Azure Search.

Has someone done this successfully? Is there a way can I reuse the documents I define in DocDB as search entities in Azure Search?

EDIT : I've already integrated with an indexer to allow for search in Azure Search, and the search itself works great. I'm now faced with the following scenario - I fetch items using a query over DocumentDB which filters on several properties. If I want to allow search with the same set of filters, I need to specify the properties I use as fields for the index. So by specifying these fields, I am essentially creating a new data model (Its a duplication of the class I have in DocumentDB)

For example, suppose I have the following class which I store in DocDB:

class MyItem
{
    public string Name { get; set;}
    public double Price { get; set; }
}

I create an Index, specifying that I want to search on the Name, and filter on the price. Now I add new functionality to the class so that it also shows availability

class MyItem
{
    public string Name { get; set;}
    public double Price { get; set; }
    public bool IsAvailable { get; set; }
}

Now I need to add IsAvailabile as a filterable field in my index, and re-index. So the field list for the indexer turns out to be a duplication of the properties for my class, also causing coupling in my code. Is there a way to effectively deal with this?

Answer 1

Many hundreds of customers are successfully using DocumentDB/Search integration. However, you need to keep in mind that while DocumentDb supports storing arbitrary JSON documents, Azure Search currently supports only "flat" documents consisting of primitive types and arrays of strings. Therefore, you may need to "flatten" your DocumentDb documents into the shape of your search schema using the query parameter of the datasource.