Re: [Discussion] Refactor dynamic configuration

Posted by Jacky Li on Oct 31, 2018; 11:58am
URL: http://apache-carbondata-dev-mailing-list-archive.168.s1.nabble.com/Discussion-Refactor-dynamic-configuration-tp67057p67179.html


Hi Xubo,

Since you have modified so many place for this feature, I think instead of adding more annotation, it is better to the CarbonProperty more object-oriented. For example, we can change the CarbonProperty to

class Property<T> {
   String name;
   T value;
   T default;
   String doc;
   boolean dynamicConfigurable;

   static PropertyBuilder<String> buildStringProperty() {…}
}

And provide property builder for it, then you can use it in CarbonCommonConstant to replace current String implementation.
For example

public static final Property CARBON_BAD_RECORDS_ACTION = Property.buildStringProperty().
        .name(“carbon.bad.records.action”)
        .default(“FAIL”)
        .doc(“keep the same description as .md file”)
        .dynamic(true)
        .build()

Then in the core module, we can still use CarbonProperties.getInstance().getProperty(CCC. CARBON_BAD_RECORDS_ACTION) to get its value.


Regards,
Jacky

> 在 2018年10月31日，下午4:07，xuchuanyin <[hidden email]> 写道：
>
> Does the annotations have other effects other than just providing literal
> coding contract?
>
> For example we can use these annotations to
> 1. generate docs
> 2. restrict some operations (for example some configurations should not
> support SET command)
> 3. limit scope for usage (for example some configurations can only be used
> during loading while some can only be used during query)
>
>
> --
> Sent from: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/
>