Use an enum for aggregator cache key byte identifiers instead of static values

[clintropolis]

Based on this discussion the idea is to use an enum instead of a pile of static variables for associating aggregators to cache keys in AggregatorUtil, and use a static initializer to ensure that it is impossible to define the same byte identifier twice. CacheKeyBuilder should also be modified to accept the enum instead of the byte value.

[clintropolis]

DimFilterUtils and ExtractionCacheHelper are probably other good candidates for this

[drcrallen]

How does this play into proprietary extensions? For example, we have a lookup extension that has a special cache key generation mechanism. Is the intention that custom extensions use this enum to generate their cache keys?

[clintropolis]

Good point @drcrallen, I'm not sure how to best handle this. @leventov as the source of this request do you have any ideas?

[leventov]

An extensible enum pattern could be used.

interface CacheKeyId {
  byte getId();
}

enum UpstreamCacheKeyId implements CacheKeyId {
  ...
  RESERVED_1((byte) 200),
  ...
  RESERVED_50((byte) 250)
}

Extensions are responsible for using ids from the reserved range.

Another option is UTF-8 style, special byte for ids from private extensions:

enum CacheKeyId {
  ...
  EXTENSION(-1)
}

Then extensions need to use two-byte identifier, the first byte is EXTENSION.id, and then their custom id.

More approaches are possible

[leventov]

Another class of scattered constants: GROUPBY_QUERY, TIMESERIES_QUERY, TOPN_QUERY.

[stale]

This issue has been marked as stale due to 280 days of inactivity. It will be closed in 4 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the dev@druid.apache.org list. Thank you for your contributions.

[clintropolis]

Still relevant

[stale]

This issue is no longer marked as stale.

[stale]

This issue has been marked as stale due to 280 days of inactivity. It will be closed in 4 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the dev@druid.apache.org list. Thank you for your contributions.