I'm still not sure it's a good design. Why do we choose to complicate two classes? There's no harm to add more configuration entries to cube desc.
The criteria to choose between cube instance and cube desc should be dynamic/static informations, retentionRange and autoMergeTimeRanges looks like static informations. On Wed, Sep 2, 2015 at 5:40 PM, Li Yang <[email protected]> wrote: > A class should do what it designed to do *only*. For me, CubeDesc defines a > cube, including dimensions, measures, aggregation policies, and that's it. > With these, it is already a complicated big class. I don't want it grow > further bigger. > > We can discuss certain metadata belongs to cube descriptor or not. > "autoMergeTimeRanges" > sounds somewhat qualified. "retentionRange" I'm not very sure. But in > general, I hope things that are not very related go to CubeInstance. > > > On Tue, Sep 1, 2015 at 7:23 PM, hongbin ma <[email protected]> wrote: > > > I'm wondering why retentionRange has to be a property on cubeintance? > > the same for autoMergeTimeRanges. > > > > It would be easier for metadata manipulation if all of such > configurations > > reside in cubedesc, > > so will reduce our frontend efforts. > > > > > > > > -- > > Regards, > > > > *Bin Mahone | 马洪宾* > > Apache Kylin: http://kylin.io > > Github: https://github.com/binmahone > > > -- Regards, *Bin Mahone | 马洪宾* Apache Kylin: http://kylin.io Github: https://github.com/binmahone
