FrankChen021 commented on PR #18087: URL: https://github.com/apache/druid/pull/18087#issuecomment-3095909468
@kgyrtkirk Thanks for the comments. I have to admitted that this contains lots of changes, let me give a description over these changes again. Generally changes in this PR can be divided into 4 parts: 1. a tiny framework to provide strong-typed parameter definition under `processing/src/main/java/org/apache/druid/setting/` directory 2. a central place to declare parameters in strong-type way in `QueryContexts`, which demonstrates how to use above framework 3. use these strong-typed parameters in `QueryContext` to simplify current manually defined getter/setter methods 4. changes in code that demonstrates how to use strong typed parameters in `QueryContext` Many changes come from 4, I make enough changes to current parameters so that they fully demonstrate how to use the new API. But as you can see, there're still lots of query context parameters kept unchaged in `QueryContexts` which can be left in follow up PR. for this PR, we need to focus on first 3, As the goal, it's similar to yours: > > * package related things together: > They're all under the package: `org.apache.druid.setting` under the directory: `processing/src/main/java/org/apache/druid/setting/` > * easy access to the typed api of the value - without a bunch of manually maintained methods > This is also my goal that eliminates lots of get/set methods defined in QueryContext for each parameter. If you look at the `QueryContext` class, it will show u how this is achieved. > * using a full type they could be worked with better...and no more `QueryContexts` and other property pool-er classes to hold them as static fields - or questions "where this property was declared" all String based prop names defined in QueryContexts have been updated as strong typed. > * for the registry they could possibly be loaded thru injector Currently I don't use injector to achieve it. But this can be implemented later. All parameters are registered in a centeralize file so that I think it would be easier for the document generation. > * possibly later generate an `md` file from them for the site.... Right, this is also what I want to achieve, we only maintains the code, and documents about this parameters are always auto generated at the building phase. > I think you were also thinking in the same direction - most likely more centered on the `sys` table as that was your main goal :) > `sys` table is a use case of above goals. -- 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]
