Modelling Complex Types in Indexes
When modelling an index the data types are restrictive. There are simple types and collections. There is nothing that allows us to model complex types e.g.
The oData spec allows for complex types
This feature is now Generally Available: https://docs.microsoft.com/en-us/azure/search/search-howto-complex-data-types
Azure Search is supposedly built on top of Elasticsearch, but is crippled with lots of seemingly artificial limitations - flat document, 512K max document size, rigid schema requirements, relatively small maximum document counts.
The flat document structure seems to indicate that the Lucene Document object is being directly used, rather than the very flexible NoSQL, document-oriented approach of Elasticsearch. Which is fine, but extremely limited compared what Lucene-based search engines like Elasticsearch and Solr have been offering for years now. Being able to define an index with a schema containing nested levels of contained sub-documents and collections is a necessity to providing developers with a search tool for rapidly building efficient search solutions.
Support for complex document structures is vital for implementing real-world scenarios. It would be great to have something similar to the way Elasticsearch handles complex document structures.
@Aaron Holmes: Can you point me at some examples of using multiple indexes? Even just a conceptual walkthrough would be appreciated.
I agree !
This can be a very useful feature. Right now it is highly inconvenient to maintain multiple indexes for my data source.
Aaron Holmes commented
Right now we're limited to modeling complex types by creating multiple indexes, which means multiple HTTP requests to assemble the full model. This is pretty inefficient, especially for very complex models, or large data sets.