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 <[email protected]> 写道：
>
> 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/
>
