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

Remove the single asterisk when converting queries to user side #10280

Merged
merged 1 commit into from
Feb 14, 2017
Merged

Remove the single asterisk when converting queries to user side #10280

merged 1 commit into from
Feb 14, 2017

Conversation

trevan
Copy link
Contributor

@trevan trevan commented Feb 9, 2017

Fixes #10272.

This removes the single * when parsing a query for human consumption. That affects the search bars in visualization, dashboard, and discover so that it shows the placeholder text the first time you load the page.

There is one place that uses parseQuery directive and doesn't have a placeholder. It is in the filters buckets in visualization. Should there be a placeholder there now that the * won't appear initially?

@elasticmachine
Copy link
Contributor

Can one of the admins verify this patch?

@Bargs Bargs self-requested a review February 9, 2017 23:30
@Bargs Bargs self-assigned this Feb 9, 2017
@Bargs
Copy link
Contributor

Bargs commented Feb 9, 2017

Hmmm that's an odd error in the Selenium tests, doesn't look related to the changes to me. @LeeDr have you seen that one before?

Functionality LGTM. @lukasolson could you give it a sanity check as well? Since you've been around longer you might know of a reason why * was chosen in the first place.

@LeeDr
Copy link
Contributor

LeeDr commented Feb 10, 2017

@Bargs the current build failure for this PR isn't in the Selenium tests.
This build: https://kibana-ci.elastic.co/job/elastic-kibana-pull-request/4014/

Goes to this elastic+kibana+pull-request+multijob-intake job: https://kibana-ci.elastic.co/job/elastic+kibana+pull-request+multijob-intake/4004/console

Which shows:

INFO - dt8HvV8 - meta_data_delete_index_service - [foo-1/rC9pAVANTTCUYxd0lgOZZg] deleting index
INFO - dt8HvV8 - meta_data_delete_index_service - [foo-2/jzj282fXS36qaoTLOMyqjA] deleting index
SUITE ERROR
Error: [version_conflict_engine_exception] [bar][1]: version conflict, document already exists (current version [1]), with { index_uuid="rC9pAVANTTCUYxd0lgOZZg" & shard="3" & index="foo-1" }
  at respond  <node_modules/elasticsearch/src/lib/transport.js:289:15>
  at checkRespForFailure  <node_modules/elasticsearch/src/lib/transport.js:248:7>
  at HttpConnector.<anonymous>  <node_modules/elasticsearch/src/lib/connectors/http.js:164:7>
  at IncomingMessage.wrapper  <node_modules/elasticsearch/node_modules/lodash/lodash.js:4968:19>
  at emitNone  <events.js:91:20>
  at IncomingMessage.emit  <events.js:185:7>
  at endReadableNT  <_stream_readable.js:974:12>
  at _combinedTickCallback  <internal/process/next_tick.js:74:11>
  at process._tickCallback  <internal/process/next_tick.js:98:9>
>> 4/4 tests failed
>> 4/4 tests failed
SKIP: scripts API - Languages API - should return 200 with an array of languages (bailed)
SKIP: scripts API - Languages API - should only return langs enabled for inline scripting (bailed)
>> 0/2 tests failed (2 skipped)
>> 0/2 tests failed (2 skipped)
>> 4/11 tests failed (2 skipped)

@Bargs
Copy link
Contributor

Bargs commented Feb 10, 2017

Whoops, my bad @LeeDr, missing the obvious. It looked like Intern output to me for some reason.

@Bargs
Copy link
Contributor

Bargs commented Feb 10, 2017

Tests passed locally :/ perhaps it was a timing issue.

jenkins, test this

@lukasolson
Copy link
Member

lukasolson commented Feb 14, 2017

This is probably a fine first step, but what I'd really like to see is when the user hasn't entered any query, default to using match_all instead of a query with *. I'm not sure why we ever defaulted to using a query of * instead of simply a match_all but I think it makes more sense than to treat an empty query string as a * query.

@Bargs
Copy link
Contributor

Bargs commented Feb 14, 2017

@lukasolson agreed, we should update that in the future.

@trevan thanks for the contribution!

@trevan
Copy link
Contributor Author

trevan commented Feb 14, 2017

@lukasolson, I created a pull request to use match_all instead of asterisk #10350. Is that what you were thinking?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants