0

I'm upgrading to Nest 1.7 from .11.

All my queries are in raw json format, and when upgrading, it appears when performing a raw query search with my query, nest appends an outer query, causing failure.

The docs say it does not modify the string, but that's not completely true - http://nest.azurewebsites.net/nest/writing-queries.html#raw-strings

Initial Query:

  {
    "query": {
      "match_all": {}
    },
    "facets": {
      "field_one": {
        "terms": {
          "field": "my_favorite_field"
        }
      }
    },
    "from": 0,
    "size": 25
  }

Call using Nest:

client.Search<MyType>(q => q.QueryRaw(query));

Converts query to: 

  {
    "query": {
      "query": {
        "match_all": {}
      },
      "facets": {
        "field_one": {
          "terms": {
            "field": "my_favorite_field"
          }
        }
      },
      "from": 0,
      "size": 25
    }
  }

The second query obviously fails. Is there any easy way to "disable" this behavior.

I'm largely trying to avoid rewriting/converting a hundred queries into the new DSL.

daviddeath
  • 2,483
  • 2
  • 17
  • 16

1 Answers1

1

A couple comments:

  1. Using raw queries with NEST is supported, but should not be the default. You should use the POCOs to generate the queries for you.
  2. Facets have been deprecated for a while now in favor of Aggregations

So I don't have a solution to your raw query issue but perhaps this is a time to convert to POCOs and convert to Aggregations.

jhilden
  • 12,207
  • 5
  • 53
  • 76
  • Converting to aggs is simple, since the syntax is nearly identical, and my version of ES still supports facets. But why should raw queries not be the default? – daviddeath Oct 29 '15 at 22:33
  • Lots of reasons: compile time validation of queries and refactoring come to mind straight away. Think about it like Entity Framework: you can write raw SQL if you want to but there are lots of advantages to using Linq-To-SQL and EF to do a lot of the grunt work for you. – jhilden Oct 29 '15 at 22:37
  • Agreed on those fronts, though I'm often passing the queries between sense/curl/etc, so it has made sense to just keep them raw. Just not sure why the client would enforce that design decision for me. Even entity still provides an ExecuteCommand, since there are many scenarios and queries that just aren't possible w/in the entity/poco design. Ideally, I prefer the control to use both when necessary. – daviddeath Oct 29 '15 at 22:43