[
https://issues.apache.org/jira/browse/LENS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15411270#comment-15411270
]
Hudson commented on LENS-197:
-----------------------------
FAILURE: Integrated in Lens-Commit-Java8 #232 (See
[https://builds.apache.org/job/Lens-Commit-Java8/232/])
LENS-197 : Allow start and end times for columns in fact tables (amareshwari:
rev 934f845737558349af00ce4de6ffcb16c6fa904b)
* lens-cube/src/main/java/org/apache/lens/cube/parse/CandidateTableResolver.java
*
lens-server/src/main/java/org/apache/lens/server/metastore/CubeMetastoreServiceImpl.java
* lens-cube/src/test/java/org/apache/lens/cube/parse/CubeTestSetup.java
* lens-api/src/main/resources/cube-0.1.xsd
* lens-cube/src/main/java/org/apache/lens/cube/parse/CubeQueryRewriter.java
* lens-cube/src/main/java/org/apache/lens/cube/metadata/MetastoreConstants.java
* lens-cube/src/test/java/org/apache/lens/cube/parse/TestQueryMetrics.java
* lens-cube/src/main/java/org/apache/lens/cube/parse/TimeRangeChecker.java
* lens-examples/src/main/resources/fact1.xml
* lens-cube/src/test/java/org/apache/lens/cube/parse/TestCubeRewriter.java
*
lens-server/src/test/java/org/apache/lens/server/metastore/TestMetastoreService.java
* lens-examples/src/test/resources/yaml/fact1.yaml
* lens-cube/src/main/java/org/apache/lens/cube/parse/TimerangeResolver.java
* lens-cube/src/test/java/org/apache/lens/cube/parse/TestBaseCubeQueries.java
* lens-server/src/main/java/org/apache/lens/server/metastore/JAXBUtils.java
> Allow start and end times for columns in fact tables
> ----------------------------------------------------
>
> Key: LENS-197
> URL: https://issues.apache.org/jira/browse/LENS-197
> Project: Apache Lens
> Issue Type: Improvement
> Components: cube
> Reporter: Amareshwari Sriramadasu
> Assignee: Sushil Mohanty
> Fix For: 2.7
>
> Attachments: LENS-197-2.patch
>
>
> We can have columns being promoted/demoted from one aggregate fact to other,
> with usage of columns in reports.
> We need this for the following use cases:
> # If field is moved to a lower cost fact: Since the fact is having lower cost
> it will be picked up for processing, but if the life of column queried does
> not fit in the range queried, a higher level fact should be picked up. If
> lower level fact is picked, it would lead to wrong results.
> # If field is moved to a higher cost fact, i.e. its life ending in a lower
> cost fact. Again, depending on the range queried, either lower or higher
> level fact should be picked up. It will be more like optimization for this
> case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
