Finalize fields in postaggs#2883
Finalize fields in postaggs#2883jaehc wants to merge 13 commits intoapache:masterfrom jaehc:finalize-fields-in-postaggs
Conversation
|
Thanks @jaehc, we'll try to get to reviewing this soon. We are really backlogged on PRs right now. |
|
rebased to master |
There was a problem hiding this comment.
can we call this FinalizingFieldAccessPostAggregator?
|
@nishantmonu51 can you help with review here? |
There was a problem hiding this comment.
this probably will not work when a dependent post agg is used within Arithmetic post aggregator.
We need to have a better way to inject aggregators instead of using instanceOf.
There was a problem hiding this comment.
A Ut for a finalizing post aggregator with arithmetic post aggregator has beed added. It seems work, but do you mean this case or other situation? Of course, I agree that we can use better ways to get aggregators injected if some. Would you give me some recommandation for this?
There was a problem hiding this comment.
I believe you are referring to testComputedInArithmeticPostAggregator.
there its only testing computation instead of dependency injection.
can you add/modify the test to call Queries.prepareAggregations() for arithmetic aggregator and verify that all dependencies are set properly ?
There was a problem hiding this comment.
@nishantmonu51 You're right. Injections of post aggs in Arithmetic post aggregator does not work because jackson injects the post aggs while creating an instance which means there is no chance to go through Queries.prepareAggregations()
There was a problem hiding this comment.
@nishantmonu51 I've made ArithmeticPostAggregator implements HasDependentAggFactories and modify a existing Ut for that(testIngestAndQueryWithArithmeticPostAggregator). It seems work so far now. But, do you think things are getting ugly?
There was a problem hiding this comment.
yeah, looking at this further, there seems to be other aggregators too which act as a wrapper for other postAggs e.g DoubleGreatestPostAggregator, LongGreatestPostAggregator etc.
To make it more cleaner, I think it might just be simpler to add new method setDependentAggFactories in interface PostAggregator itself. Any implementation not having any dependent post aggregator will have a no-op implementation.
There was a problem hiding this comment.
@nishantmonu51 It makes sense to me, I will add setDependentAggFactories in PostAggregator and maybe I guess we would probably need another contextual information later and think about it then.
|
@jaehc: can you address #2883 (comment) ? |
|
ping @jaehc |
|
@fjy @nishantmonu51 sorry for being late. I will handle it |
|
@nishantmonu51 |
|
LGTM, with the changes for decorate. @fjy Can you also review ? |
|
updated the master comment to change finalFieldAccess -> finalizingFieldAccess |
|
Incompatibilities need called out in the master comment, please |
|
@nishantmonu51 Thanks for giving a review. Is there somethign I need to handle about this PR? By the way, what is |
|
@jaehc master comment is the top comment in the issue at #2883 (comment) |
|
Taking a look. |
There was a problem hiding this comment.
Could you please add a javadoc to this explaining what it's supposed to do, and what aggregators is expected to contain? It's not clear from the method type signature how this would work.
There was a problem hiding this comment.
You're right. It needs more explanation. I put some comments on it.
There was a problem hiding this comment.
This should override getComparator too, so the post-aggregator can be sorted on. This should be possible by using the comparator of aggregators.get(fieldName).getComparator() if that exists, and Ordering.natural().nullsFirst() otherwise (hoping for the best).
There was a problem hiding this comment.
That sound good to me. But, why do we use Ordering.natural().nullsFirst() other than only Ordering.natural()?
There was a problem hiding this comment.
Just in case there's a null return value from a postaggregator, I guess.
There was a problem hiding this comment.
name=' is missing the equals sign
There was a problem hiding this comment.
Seems like postAggregatorSpecs == null ? ImmutableList.<PostAggregator>of() : postAggregatorSpecs is a common pattern, might as well have Queries.prepareAggregations do this.
There was a problem hiding this comment.
Is there somewhere to apply it other than the line number of 125?
There was a problem hiding this comment.
I meant, Queries.prepareAggregations could do this… return an empty list if postAggregatorSpecs is null. This is minor thing and not really necessary though.
There was a problem hiding this comment.
Please add a test for the comparator too.
There was a problem hiding this comment.
done with testComparatorsWithFinalizing and the below Ut.
There was a problem hiding this comment.
minor: name this decoratePostAggregators? Or move to PostAggregators.decorate? The name "Queries.decorate" sounds a little too generic for what this does.
There was a problem hiding this comment.
That sound good to me. It was somewhat obscure. For now, I rather lean to rename it. But, when we find out another things doing stuff with post aggregators, it would be good to be in a separated class like PostAggregators.decorate()
jaehc
left a comment
There was a problem hiding this comment.
A patch to address comments.
There was a problem hiding this comment.
Is there somewhere to apply it other than the line number of 125?
There was a problem hiding this comment.
That sound good to me. It was somewhat obscure. For now, I rather lean to rename it. But, when we find out another things doing stuff with post aggregators, it would be good to be in a separated class like PostAggregators.decorate()
There was a problem hiding this comment.
You're right. It needs more explanation. I put some comments on it.
There was a problem hiding this comment.
That sound good to me. But, why do we use Ordering.natural().nullsFirst() other than only Ordering.natural()?
1. Implements getComparator in FinalizingFieldAccessPostAggregator and add Uts for it 2. Some minor changes like renaming a method name.
|
@jaehc thanks, re-reviewing. |
|
I will take a look at resolving conflicts for this patch for 0.10.0. |
|
Opened #3957 with conflicts fixed, otherwise unchanged. |
According to #2433, automatically finalizing aggregators in a post aggregator sounds really good to druid client programs.
I gave it a try to make it work and it seems good. Now, you can write a query like the below. However, there are some duplicate code blocks here and there. Any comments on refactoring would be welcomed.
instead of
This change is