bitemyapp / bloodhound

Haskell Elasticsearch client and query DSL
bitemyapp.com
BSD 3-Clause "New" or "Revised" License
424 stars 118 forks source link

Breaking Changes between 1.x and 2.x api's #134

Open alistair opened 8 years ago

alistair commented 8 years ago

This is a issue to enable discussion on api changes which have occurred between elasticsearch 1.x and 2.x.

As an example https://www.elastic.co/guide/en/elasticsearch/reference/2.3/breaking_20_query_dsl_changes.html#_filter_auto_caching

I'm raising this as a direct result of looking into the hspec test "returns document for geo boundingbox filter". This is failing (in part) due to the _cache option being removed from the api.

What I would like input on is how you would like to handle the different versions of ES. We could potentially do a number of different options.

Being new to Haskell i'm not sure what the 'normal' approach is around version support.

For reference https://www.elastic.co/support/eol Ah I see that aws does have both 1.5 and 2.3 versions of elasticsearch. http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-version-migration.html

alistair commented 8 years ago

https://www.elastic.co/guide/en/elasticsearch/reference/2.0/breaking_20_query_dsl_changes.html

Filtered query and query filter deprecated

The query filter is deprecated as is it no longer needed — all queries can be used in query or filter context. The filtered query is deprecated in favour of the bool query. Instead of the following:

GET _search
{
  "query": {
    "filtered": {
      "query": {
        "match": {
          "text": "quick brown fox"
        }
      },
      "filter": {
        "term": {
          "status": "published"
        }
      }
    }
  }
}

move the query and filter to the must and filter parameters in the bool query:

GET _search
{
  "query": {
    "bool": {   
      "must": {
        "match": {
          "text": "quick brown fox"
        }
      },
      "filter": {
        "term": {
          "status": "published"
        }
      }
    }
  }
}

I can't say i'm an expert at the bloodhound api, but i'm going to say that this would be a breaking api or at least make documenting that certain combinations of types would only work for specific versions of elasticsearch. This would be possible with dependant types I think which would be a really cool learning experience but doesn't help one bit currently.

data BoolQuery apiVersion x y z where apiVersion == ES1 then y == Nothing

im showing my c# background here :(

It seems like either we aim for something really strongly typed or we accept someone can define an invalid query.

bitemyapp commented 8 years ago

/cc @MichaelXavier

bitemyapp commented 8 years ago

I'm not keen on making the API more complicated in order to handle multiple-ES support. Please look at past issues/PRs where we've discussed this to get an idea of what we're warm to or not.

This is the main one I believe: https://github.com/bitemyapp/bloodhound/issues/101

MichaelXavier commented 8 years ago

Would ES 1 understand the version that ES2 supports and are they semantically equivalent? If so, we could just change how the deprecated case is encoded and punt for another day.