Skip to content

Clean up query contexts#12633

Merged
gianm merged 2 commits intoapache:masterfrom
paul-rogers:220610-context
Jun 15, 2022
Merged

Clean up query contexts#12633
gianm merged 2 commits intoapache:masterfrom
paul-rogers:220610-context

Conversation

@paul-rogers
Copy link
Copy Markdown
Contributor

Query context cleanup in support of the planner test framework PR. This PR splits up the files from the planner test PR to make review a bit easier.

  • Uses QueryContext constants in place of literal string keys for several commonly-used keys.
  • Moves some context-related implementations from QueryContext to QueryContexts so that they can be reused, such as in the planner tests.

No functional changes; only refactoring.


This PR has:

  • been self-reviewed.
  • added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
  • added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.

Uses constants in place of literal strings for context keys.
Moves some QueryContext methods to QueryContexts for reuse.
@paul-rogers paul-rogers mentioned this pull request Jun 10, 2022
5 tasks
Copy link
Copy Markdown
Contributor

@gianm gianm left a comment

Choose a reason for hiding this comment

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

Generally looks good. Just wanted to sort out the differences between parse stuff and getAs stuff.

public static <T> int getUncoveredIntervalsLimit(Query<T> query, int defaultValue)
{
return parseInt(query, "uncoveredIntervalsLimit", defaultValue);
return parseInt(query, UNCOVERED_INTERVALS_LIMIT_KEY, defaultValue);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there any reason for parseInt and getAsInt to remain different? Now that we have getAsInt, shall it replace parseInt?

(Btw, is the behavior the same? I haven't checked)

public static <T> boolean isSerializeDateTimeAsLongInner(Query<T> query, boolean defaultValue)
{
return parseBoolean(query, "serializeDateTimeAsLongInner", defaultValue);
return parseBoolean(query, SERIALIZE_DATE_TIME_AS_LONG_INNER_KEY, defaultValue);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is there any reason for parseBoolean and getAsBoolean to remain different? Now that we have getAsBoolean, shall it replace parseBoolean?

(Btw, is the behavior the same? I haven't checked)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Good point. I didn't really pay attention to the parseFoo methods. Those methods appear to only handle the value-as-string case, where as the getAsFoo method handle maps with values of the expected type. Went ahead and changed the parseFoo methods to use getAsFoo so we're consistent.

@gianm gianm merged commit 45e3111 into apache:master Jun 15, 2022
@abhishekagarwal87 abhishekagarwal87 added this to the 24.0.0 milestone Aug 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants