[
https://issues.apache.org/jira/browse/LENS-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15867663#comment-15867663
]
Rajat Khandelwal commented on LENS-974:
---------------------------------------
The third approach is to do some design change in the resolver flow. From the
current approach of `populate-all-prune-most`, towards the radically different
approach of `process-the-strongest-ignore-the-rest`. We need not go to the
other extreme, we can arrive at an approach which is a mix of both. One such
natural boundary is `LightestFirstResolver`. Everything that happens before
this resolver can keep working in `populate-all-prune-most` mode. Everything
that happens after this can work in the other mode. Or, we can change all
resolvers to the second mode. In any case, how would one go about doing that?
Looking at the resolvers, two kind of things happen in all resolvers. One is
the processing on the shared object i.e. `cubeql`. The other is evaluation and
pruning of candidates. Secondly, there is some code sharing via static methods
across the resolvers. So the boundary between resolvers not very sharp anyway.
The code for shared processing can stay in the resolver itself and the code
inside the loop while evaluating candidates can move to the candidate
interface. Another reason for doing this would be that all the resolvers will
now have multiple instanceof checks, Which can be easily solved by
polymorphism. After this separation, another layer of optimization becomes
possible. Each resolver can run the shared processing first (which will do
write operations on cubeql) and then fork off threads for each candidate to
evaluate itself (which should only do only read operations on cubeql).
> Add cube-segmentation for base cube
> -----------------------------------
>
> Key: LENS-974
> URL: https://issues.apache.org/jira/browse/LENS-974
> Project: Apache Lens
> Issue Type: New Feature
> Components: cube
> Reporter: Sushil Mohanty
>
> With cube segmentation a cube can have multiple cubes and all these child
> cubes together will make the cube complete.
> CubeSegmentation and CubeFactTable will sit together, which means it can
> belong to only one base cube. A base cube can have one or more cube
> segmentations. Fields of segmentation will be intersection of all columns of
> its cubes. Segmentation will have weight to compare with its buddies (facts
> or other segmentations). Also it can have start and end time defined or it
> can derive from its underline facts.
> eg:
> base_cube
> |_fact1
> |_fact2
> |_cube_segment1
> |_cube1
> |_fact_11
> |_fact_12
> ...
> ...
> |_cube_segment2
> |_cube2
> |_fact_21
> |_fact_22
> ...
> ...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
