Hi,
Please check my views on it.
Basic design should be there is a clear separation between modules. Like
Spark based configurations are no means to presto, So every module can have
there owned conf and constant classes.
1. No need for CarbonProperties and CarbonCommonConstants.
2. Should have
I rasie a PR for it and write a
demo:https://github.com/apache/carbondata/pull/2914
Please check it.
If the demo is ok, I will change other properties in this PR
--
Sent from:
http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/
ok, this is better:
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()
I will raise
the annotation mainly providing literal explain whether this parameter can be
dynamic configurable. What's more, it will throw exception if add
@CarbonProperty and can't be dynamic configurable. If don't add
@CarbonProperty for parameter, it won't throw exception and also won't take
effect
--
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 {
String name;
T value;
T default;
String doc;
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
*Background:*
In CarbonData, there are many configuration in:
org.apache.carbondata.core.constants.CarbonCommonConstants,
org.apache.carbondata.core.constants.CarbonV3DataFormatConstants,
org.apache.carbondata.core.constants.CarbonLoadOptionConstants;
and so on. Which one can be dynamic
