Elastic 7.10 field type "version"

Elastic Stack Elasticsearch
1

First, create new index with mappings, one field has type "version":

curl -X PUT "localhost:9200/version_test_v2?pretty" -H 'Content-Type: application/json' -d'
{
  "mappings": {
    "properties": {
      "version": {         
          "type": "version"
        }
    }
  }
}
'

And index one document:

curl -X POST "localhost:9200/version_test_v2/_doc/?pretty" -H 'Content-Type: application/json' -d'
{
"version": "20.04"
}
'

And when I try to search by version range with such query:

{
  "query": {
    "range": {
      "version": {
        "gt": "79.4"
      }
    }
  },
  "explain": true
}

And indexed element returned in result of this query, but wrong, because 20.04 < 79.4
Explanation doesn't help much:

"description": "version:{[1 82 37 39 2e 1 81 34 3] TO *]"
2

I can reproduce this behavior. It looks like to me a bug. @cbuescher WDYT? Here is the full script:

DELETE /test 
PUT /test
{
  "mappings": {
    "properties": {
      "version": {         
          "type": "version"
        }
    }
  }
}
POST /test/_doc
{
  "version": "20.04"
}
GET /test/_search
{
  "query": {
    "range": {
      "version": {
        "gt": "79.4"
      }
    }
  }
}
3

Actually when you change 20.04 with 20.4 this works well:

DELETE /test 
PUT /test
{
  "mappings": {
    "properties": {
      "version": {         
          "type": "version"
        }
    }
  }
}
POST /test/_doc
{
  "version": "20.4"
}
GET /test/_search
{
  "query": {
    "range": {
      "version": {
        "gt": "79.4"
      }
    }
  }
}

Gives:

{
  "took" : 2,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 0,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  }
}
4

Yes, also find this behaviour now. But while index document don't receive any error about non-valid version format.

5

This is the reason this works unexpected for you. "20.04" is not a valid version according to Semver (www.semver.org). Leading zeros are not allowed in major, minor or patch. We chose to treat "shorter" version string that otherwise satisfy the Semver definition as "valid" (that is why 79.4 an 20.4 are treated as valid).
The docs state that we accept "invalid" versions such as "20.04" at index time. This is done to make it possible for users of the old "keyword" field that used to be used a lot for version data can transition to the new field type without disruption. However, "invalid" versions will be sorted after all valid ones, hence "79.4" < "20.04" here.

1 Like
6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.