I think it's a good idea.
In particular, https://github.com/apache/incubator-druid/pull/7512 and
https://github.com/apache/incubator-druid/pull/7520 affect the ability to
do rolling updates successfully for people using native Kafka or
parallel-batch indexing. In datasketches land,
Hi all,
I know the 0.15 code freeze is just around the corner, but
0.14.0-incubating release has a few issues out of the box so in the
interest of getting fixes for these shipped as soon as possible I wanted to
propose a 0.14.1 release. I went through the set of commits and picked out
bug fixes
> I'm inclined to say the expected data shape returned should be preserved.
This seems like a good general principle. Callers generally are happier
when the result shape is consistent. I have to admit, I don't understand
why an empty array would be better than null or vice versa. Both are a
Hey Roman,
Thank you too for participating.
> Apart from code review friction, I think there is another important
> (ultimately, more important) problem/goal for the long term project
success
> which cannot be discussed separately: keeping the codebase highly
> maintainable. I'm a Druid
> I'm inclined to say the expected data shape returned should be preserved.
Agreed, I think the array of NaNs is the most correct return value in the
case described there (and
org.apache.druid.query.aggregation.histogram.FixedBucketsHistogram#percentilesFloat
should be adjusted to that match
Hi all!
If you do not use approximate quantiles (or histograms or quantiles
double sketch) then you can stop reading.
https://github.com/apache/incubator-druid/issues/7486 brings up an
issue related to how objects are returned from Druid aggregations,
specifically when the input aggregation
Hey Slim,
Thanks for reading. Some thoughts inline -
>> 1) "Let robots handle style checks."
> OMG Gian, are you taking away all the fun? what is code review without
> arguing about the meaning of life and code style, variable names etc ??
> Totally agree, we need to avoid as much as possible
