ankitsultana commented on code in PR #16167:
URL: https://github.com/apache/pinot/pull/16167#discussion_r2164796525
##########
pinot-broker/src/main/java/org/apache/pinot/broker/requesthandler/TimeSeriesRequestHandler.java:
##########
@@ -119,8 +122,10 @@ public PinotBrokerTimeSeriesResponse
handleTimeSeriesRequest(String lang, String
return PinotBrokerTimeSeriesResponse.newErrorResponse("BAD_REQUEST",
"Error building RangeTimeSeriesRequest");
}
TimeSeriesLogicalPlanResult logicalPlanResult =
_queryEnvironment.buildLogicalPlan(timeSeriesRequest);
+ TableScanVisitor.Context scanVisitorContext =
TableScanVisitor.createContext(requestContext.getRequestId());
Review Comment:
(nit / opinionated)
I think this is a code-smell:
1. We create a context here, it is populated indirectly in buildPhysicalPlan
and then used in tableLevelAccessControlCheck.
2. The context is not really related to Physical Plan generation. I think
initially this visitor was supposed to be an impl detail nested in
buildPhysicalPlan.
3. Ideally Context objects are very short lived and imo shouldn't leave the
method where they are created. Instead well formed objects should be used.
4. Note that the scan visitor also requires initialization which is taken
care of by QueryEnvironment#init.
I think a better way would be to add a tableNames member in
TimeSeriesDispatchablePlan. It can be populated using the same Context that you
are using but then the Context won't be leaked outside that method and will be
short lived, with its only purpose being to create the dispatchable plan.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
