IMO, retentionRange and autoMergeRanges are "metadata" just like
"filter" conditions, it describe how a cube to pull and maintain a data
range,

As our design pattern, cube desc contains static information and cube
instance
contains runtime information, then I would like to say those two properties
should
belong to cube desc.

Thanks.



Best Regards!
---------------------

Luke Han

On Wed, Sep 2, 2015 at 5:50 PM, hongbin ma <[email protected]> wrote:

> 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
>

Reply via email to