How can we improve Azure Search?

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.

...
"name": {
"first": "Ericka",
"last": "Banks"
},......

The oData spec allows for complex types

http://www.odata.org/documentation/odata-version-2-0/overview/

1,229 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Anonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    We are ready to onboard more customers who are interested in participating in the private preview of Complex Types. If you’re interested, please contact us at azuresearch_contact@microsoft.com.

    Please note that the private preview of Complex Types is only accessible via the REST API. We are working on .NET SDK support for the Public Preview.

    Also, if you get an error message when you email azuresearch_contact, don’t worry — we are receiving your requests and will reply to you individually.

    Thanks!

    21 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Zach Bergman commented  ·   ·  Flag as inappropriate

        Awesome that this has been started. Is there any information you can provide regarding an ETA of the feature? It seems to be 11 months into development - Can't wait to use it :)

      • Dean Peters commented  ·   ·  Flag as inappropriate

        Hey Azure Team, one of the primary reasons we would have to adopt Elastic or Solr is the inability of Azure Search to support complex objects.

        Where are we with this initiative? How long does one have to wait to request addition to the private preview.

      • AdminThe Azure Team on UserVoice (Admin, Microsoft Azure) commented  ·   ·  Flag as inappropriate

        We have received your requests, even though you're getting an error message back. It looks like our public distribution list includes a private list as a member, which is why you're seeing the error. I'll see if we can get it fixed. Please let us know by posting here if you do not receive a reply from us. Thanks!

      • Gutemberg Ribeiro commented  ·   ·  Flag as inappropriate

        We are unable to get in touch by that distribution list as it is configured to allow only messages fro inside MSFT as per this message returned:

        > The group azsearch only accepts messages from people in its organization or on its allowed senders list, and your email address isn't on the list.

      • Graham Bunce commented  ·   ·  Flag as inappropriate

        Usual bump that will get ignored...

        This really doesn't help much where you want to facet by hierarchical type, but only some of those facets, i.e. a customer can add their own facets to a item in the index. When they search, they want to see their facets but not for the 1000 other customers in the same index. The way you force us to do this, I think, is that we implement something like you state above (e.g. customer key|facet name) and then when search we have to pull back *all* the facets of this type, regardless of the customer we're actually searching under. I then need to perform client-side parsing to discard the 99% of the facet results that I don't need.

        How is this even remotely scalable? What if I have 1000 customers with 100 facets each.... I need to do a facet, count:100000... I mean come on... seriously?

      • BB commented  ·   ·  Flag as inappropriate

        Make json as another data type within same index.
        for eg. If we have Asset Index with the following fields
        Id string , key
        Location : geography Point
        CurrentState : string
        ReadyForFieldWork : boolean
        Tags : String Collection
        FieldData : Json

        provide some way to search the json datatype with filter

        Same concept can be applied to other document types as well , pdf , word, text file and so on.

        This will eliminate the possibility of maintain two different indexes( one for properties and one for blobs)

      • Adam Łepkowski commented  ·   ·  Flag as inappropriate

        Usage of mutiple indexes will not work if you have a dynamic structure of the model (fully configurable by ther user).

      • dave.a commented  ·   ·  Flag as inappropriate

        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.

      • dave.a commented  ·   ·  Flag as inappropriate

        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.

      • Avinash commented  ·   ·  Flag as inappropriate

        This can be a very useful feature. Right now it is highly inconvenient to maintain multiple indexes for my data source.

      ← Previous 1

      Feedback and Knowledge Base