Indexing a document fails when setting version=0 & version_type=external
#5662
Comments
|
This is a regression added here, but it was the already documented behavior in 0.90:
Personally, I think that it is an improvement, particularly because it matches the existing documentation and it makes sense to start at |
|
Hi - Just to add, I think it would be incorrect to assume that the version numbers would always be positive. In our system, the first version number is zero and hence 1.1 failed for me as soon as we deployed and we had to revert. |
|
@amitsoni13 I agree. @pickypg Although it was documented we didn't enforce it on the 0.90 and 1.0 so people could in practice index document with version 0 so they now have it in their index. I will be working to make 0 a valid external version. |
|
@bleskes Sounds good to me. I'm curious though, are you going to make |
|
@pickypg I believe you refer to the internal version type where ES is in charge of managing versions - this will not change at it will start at |
Until now all version types have officially required the version to be a positive long number. Despite of this has being documented, ES versions <=1.0 did not enforce it when using the `external` version type. As a result people have succesfully indexed documents with 0 as a version. In 1.1. we introduced validation checks on incoming version values and causing indexing request to fail if the version was set to 0. While this is strictly speaking OK, we effectively have a situation where data already indexed does not match the version invariant. To be lenient and adhere to spirit of our data backward compatibility policy, we have decided to allow 0 as a valid external version type. This is somewhat complicated as 0 is also the internal value of `MATCH_ANY`, which indicates requests should succeed regardles off the current doc version. To keep things simple, this commit changes the internal value of `MATCH_ANY` to `-3` for all version types. Since we're doing this in a minor release (and because versions are stored in the transaction log), the default `internal` version type still accepts 0 as a `MATCH_ANY` value. This is not a problem for other version types as `MATCH_ANY` doesn't make sense in that context. Closes elastic#5662
Until now all version types have officially required the version to be a positive long number. Despite of this has being documented, ES versions <=1.0 did not enforce it when using the `external` version type. As a result people have succesfully indexed documents with 0 as a version. In 1.1. we introduced validation checks on incoming version values and causing indexing request to fail if the version was set to 0. While this is strictly speaking OK, we effectively have a situation where data already indexed does not match the version invariant. To be lenient and adhere to spirit of our data backward compatibility policy, we have decided to allow 0 as a valid external version type. This is somewhat complicated as 0 is also the internal value of `MATCH_ANY`, which indicates requests should succeed regardles off the current doc version. To keep things simple, this commit changes the internal value of `MATCH_ANY` to `-3` for all version types. Since we're doing this in a minor release (and because versions are stored in the transaction log), the default `internal` version type still accepts 0 as a `MATCH_ANY` value. This is not a problem for other version types as `MATCH_ANY` doesn't make sense in that context. Closes #5662
clintongormley
added
the
:Distributed/CRUD
This is a regression introduced in 4e0e406 , which was release with 1.1
The text was updated successfully, but these errors were encountered: