amansinha100 commented on a change in pull request #1728: DRILL-7089: Implement caching for TableMetadataProvider at query level and adapt statistics to use Drill metastore API URL: https://github.com/apache/drill/pull/1728#discussion_r272846760
########## File path: exec/java-exec/src/main/java/org/apache/drill/exec/planner/logical/DrillTable.java ########## @@ -49,9 +50,7 @@ private final String userName; private GroupScan scan; private SessionOptionManager options; - // Stores the statistics(rowcount, NDV etc.) associated with the table - private DrillStatsTable statsTable; - private TupleMetadata schema; + private MetadataProviderManager metadataProviderManager; Review comment: The fact that the DrillTable has a reference to the `MetadataProviderManager` rather than the `MetadataProvider` itself is significant..I suppose you are following a particular Design Pattern .. probably the Facade Pattern [1] ? The MetadataProvider also follows the Builder pattern, so there's 2 levels of indirection: Manager --> Provider --> Builder. My initial thought was that 'do we need both or could a Provider be able to create instances for multiple tables, so a Provider --> Builder be sufficient ? Your approach is that there's a 1-to-many relationship between Manager-->Provider and a 1-to-1 relationship between a Provider and its associated DrillTable. Is that correct ? [1] https://en.wikipedia.org/wiki/Facade_pattern ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
