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

Migrate deprecated match query syntax #11554

Merged
merged 6 commits into from May 5, 2017

Conversation

Projects
None yet
6 participants
@Bargs
Contributor

Bargs commented May 1, 2017

Fixes #10653

Since I'm considering not doing a full blown re-write of the existing filter model I wanted to get this taken care in a smaller way so we're not taken by surprise when the deprecated syntax disappears in 6.0.

@Bargs Bargs requested review from weltenwort and lukasolson May 1, 2017

@lukasolson lukasolson self-assigned this May 1, 2017

@tbragin tbragin added the :Discovery label May 2, 2017

@lukasolson

Hmm, I guess my concern here is that, as of now, you can still manually edit the query DSL for a given filter by clicking on the "edit" button. Seems to me that it would make sense to also use this migrateFilter in the mapFilter module so that if someone edits the DSL, we actually send what they specify. Thoughts @Bargs?

@@ -0,0 +1,19 @@
import _ from 'lodash';
export function migrateFilter(filter) {

This comment has been minimized.

@lukasolson

lukasolson May 2, 2017

Member

Could you add a unit test for this?

@lukasolson

lukasolson May 2, 2017

Member

Could you add a unit test for this?

This comment has been minimized.

@Bargs

Bargs May 4, 2017

Contributor

👍 f2798b5

@Bargs

Bargs May 4, 2017

Contributor

👍 f2798b5

@Bargs

This comment has been minimized.

Show comment
Hide comment
@Bargs

Bargs May 2, 2017

Contributor

I'm not sure what you mean by "if someone edits the DSL, we actually send what they specify". Can you give me an example?

Contributor

Bargs commented May 2, 2017

I'm not sure what you mean by "if someone edits the DSL, we actually send what they specify". Can you give me an example?

@lukasolson

This comment has been minimized.

Show comment
Hide comment
@lukasolson

lukasolson May 2, 2017

Member

I mean when they click on the edit button in the filter popover:

image

Member

lukasolson commented May 2, 2017

I mean when they click on the edit button in the filter popover:

image

@Bargs

This comment has been minimized.

Show comment
Hide comment
@Bargs

Bargs May 4, 2017

Contributor

@lukasolson @weltenwort ready for another look

Contributor

Bargs commented May 4, 2017

@lukasolson @weltenwort ready for another look

@lukasolson

LGTM! Made one minor comment about the test below.

match_all: {}
};
const migratedFilter = migrateFilter(originalFilter);
expect(migratedFilter).to.be(originalFilter);

This comment has been minimized.

@lukasolson

lukasolson May 4, 2017

Member

Maybe you could add to this test

expect(migratedFilter).to.not.eql(newMatchPhraseFilter);

Just to make sure that the filter hasn't been modified.

@lukasolson

lukasolson May 4, 2017

Member

Maybe you could add to this test

expect(migratedFilter).to.not.eql(newMatchPhraseFilter);

Just to make sure that the filter hasn't been modified.

This comment has been minimized.

@Bargs

Bargs May 4, 2017

Contributor

Good point, would the following be better though?

expect(_.isEqual(migratedFilter, originalFilter)).to.be(true);
@Bargs

Bargs May 4, 2017

Contributor

Good point, would the following be better though?

expect(_.isEqual(migratedFilter, originalFilter)).to.be(true);

This comment has been minimized.

@lukasolson

lukasolson May 4, 2017

Member

Either way is really fine... I prefer to.eql because when you use the syntax you've suggested, then the error is reported as something like "expected false to be true" instead of "expected { foo: bar } to sort of equal { foo: baz }" or whatever.

@lukasolson

lukasolson May 4, 2017

Member

Either way is really fine... I prefer to.eql because when you use the syntax you've suggested, then the error is reported as something like "expected false to be true" instead of "expected { foo: bar } to sort of equal { foo: baz }" or whatever.

This comment has been minimized.

@Bargs

Bargs May 4, 2017

Contributor

I talking more about the idea of checking the equality between migratedFilter and originalFilter instead of checking that migratedFilter is not eql to newMatchPhraseFilter. It seems that the former would catch more errors, but I wasn't sure if I was missing something about what you were suggesting.

As an aside, I agree that the error reporting sucks when using _.isEqual but the problem I have with expect.js's eql function is that it uses loose equality (==) so there are subtle bugs it would miss. Another reason I wish we were using Chai.

@Bargs

Bargs May 4, 2017

Contributor

I talking more about the idea of checking the equality between migratedFilter and originalFilter instead of checking that migratedFilter is not eql to newMatchPhraseFilter. It seems that the former would catch more errors, but I wasn't sure if I was missing something about what you were suggesting.

As an aside, I agree that the error reporting sucks when using _.isEqual but the problem I have with expect.js's eql function is that it uses loose equality (==) so there are subtle bugs it would miss. Another reason I wish we were using Chai.

This comment has been minimized.

@Bargs

Bargs May 5, 2017

Contributor
@Bargs

Bargs May 5, 2017

Contributor

@Bargs Bargs merged commit b984a19 into elastic:master May 5, 2017

2 checks passed

CLA Commit author is a member of Elasticsearch
Details
kibana-ci Build finished.
Details

Bargs added a commit to Bargs/kibana that referenced this pull request May 5, 2017

Migrate deprecated match query syntax (elastic#11554)
Since I'm considering not doing a full blown re-write of the existing filter model I wanted to get this taken care in a smaller way so we're not taken by surprise when the deprecated syntax disappears in 6.0.

Bargs added a commit that referenced this pull request May 5, 2017

Migrate deprecated match query syntax (#11554) (#11624)
Since I'm considering not doing a full blown re-write of the existing filter model I wanted to get this taken care in a smaller way so we're not taken by surprise when the deprecated syntax disappears in 6.0.

@epixa epixa added the v6.0.0-alpha2 label May 17, 2017

Dreadnoth added a commit to Dreadnoth/kibana that referenced this pull request Aug 8, 2017

Migrate deprecated match query syntax (elastic#11554) (elastic#11624)
Since I'm considering not doing a full blown re-write of the existing filter model I wanted to get this taken care in a smaller way so we're not taken by surprise when the deprecated syntax disappears in 6.0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment