Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rebase keyed JSON ordinals to start from zero. #41282

Merged
merged 5 commits into from
Apr 17, 2019

Conversation

jtibshirani
Copy link
Contributor

This PR updates KeyedJsonAtomicFieldData to always return ordinals in the
range [0, (maxOrd - minOrd)], which is necessary for certain aggregations and
sorting options to be supported.

As discussed in #41220, I opted not to support
KeyedIndexFieldData#getOrdinalMap, as it would add substantial complexity.
The one place this affects is the 'low cardinality' optimization for terms
aggregations, which now needs to be disabled for keyed JSON fields.

It was fairly difficult to incorporate this change, and I have a couple
follow-up refactors in mind to help simplify the global ordinals code. (I will
likely wait until this feature branch is merged though before opening PRs on
master).

@jtibshirani jtibshirani added >enhancement :Search Foundations/Mapping Index mappings, including merging and defining field types labels Apr 17, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search

Copy link
Contributor

@jimczi jimczi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks great, thanks for iterating @jtibshirani

@@ -421,7 +424,8 @@ public IndexOrdinalsFieldData localGlobalDirect(DirectoryReader indexReader) thr

@Override
public OrdinalMap getOrdinalMap() {
return delegate.getOrdinalMap();
throw new UnsupportedOperationException("Keyed JSON field data does not allow access to the" +
" underlying ordinal map.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you add the field name to the error message to make it easier to debug?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@@ -111,6 +112,15 @@ public abstract SortedSetDocValues ordinalsValues(LeafReaderContext context)
public abstract SortedSetDocValues globalOrdinalsValues(LeafReaderContext context)
throws IOException;

/**
* Whether this values source is able to provide a mapping between global and segment ordinals,
* by returning the underlying {@link OrdinalMap}. If this method returnns false, then calling
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/returnns/returns/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@jtibshirani
Copy link
Contributor Author

@elasticmachine run elasticsearch-ci/1

@jtibshirani jtibshirani merged commit a62bf1e into elastic:object-fields Apr 17, 2019
@jtibshirani jtibshirani deleted the rebase-global-ords branch April 17, 2019 18:43
jtibshirani added a commit that referenced this pull request May 1, 2019
This PR updates `KeyedJsonAtomicFieldData` to always return ordinals in the
range `[0, (maxOrd - minOrd)]`, which is necessary for certain aggregations and
sorting options to be supported.

As discussed in #41220, I opted not to support
`KeyedIndexFieldData#getOrdinalMap`, as it would add substantial complexity.
The one place this affects is the 'low cardinality' optimization for terms
aggregations, which now needs to be disabled for keyed JSON fields.

It was fairly difficult to incorporate this change, and I have a couple
follow-up refactors in mind to help simplify the global ordinals code. (I will
likely wait until this feature branch is merged though before opening PRs on
master).
jtibshirani added a commit that referenced this pull request May 24, 2019
This PR updates `KeyedJsonAtomicFieldData` to always return ordinals in the
range `[0, (maxOrd - minOrd)]`, which is necessary for certain aggregations and
sorting options to be supported.

As discussed in #41220, I opted not to support
`KeyedIndexFieldData#getOrdinalMap`, as it would add substantial complexity.
The one place this affects is the 'low cardinality' optimization for terms
aggregations, which now needs to be disabled for keyed JSON fields.

It was fairly difficult to incorporate this change, and I have a couple
follow-up refactors in mind to help simplify the global ordinals code. (I will
likely wait until this feature branch is merged though before opening PRs on
master).
jtibshirani added a commit that referenced this pull request May 29, 2019
This PR updates `KeyedJsonAtomicFieldData` to always return ordinals in the
range `[0, (maxOrd - minOrd)]`, which is necessary for certain aggregations and
sorting options to be supported.

As discussed in #41220, I opted not to support
`KeyedIndexFieldData#getOrdinalMap`, as it would add substantial complexity.
The one place this affects is the 'low cardinality' optimization for terms
aggregations, which now needs to be disabled for keyed JSON fields.

It was fairly difficult to incorporate this change, and I have a couple
follow-up refactors in mind to help simplify the global ordinals code. (I will
likely wait until this feature branch is merged though before opening PRs on
master).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>enhancement :Search Foundations/Mapping Index mappings, including merging and defining field types
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants