[
https://issues.apache.org/jira/browse/KYLIN-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097804#comment-15097804
]
hongbin ma commented on KYLIN-1313:
-----------------------------------
hi yerui:
to answer your questions:
* With the 'heavy deriving' supporting, the current 'light weight deriving'
will be still reserved or not? There seems no conflicting between these two
deriving features;
still reserved, actually they're independent functionalities
* Is it possible to support one-to-many deriving? In your example, suppose
there's one more column called item_description, is it possible to fetch
both item_url and item_description by item_id filtering?
it's included in current work plan
* Why don't we backport this feature to 1.x-staging branch? We really need
this feature in 1.x-staging production environments, and I'm not is there
any unsolvable problems for backporting?
maintaining multiple versions is a costly work. i'm not sure whether we
should always append new features to both 1.x and 2.x, after all we
encourage users to upgrade to 2.x ASAP. (We're preparing for releasing 2.0
now.) Yet it's still not decided.
--
Regards,
*Bin Mahone | 马洪宾*
Apache Kylin: http://kylin.io
Github: https://github.com/binmahone
> Enable deriving dimensions on non PK/FK
> ---------------------------------------
>
> Key: KYLIN-1313
> URL: https://issues.apache.org/jira/browse/KYLIN-1313
> Project: Kylin
> Issue Type: Improvement
> Reporter: hongbin ma
> Assignee: hongbin ma
>
> currently derived column has to be columns on look table, and the derived
> host column has to be PK/FK(It's also a problem when the lookup table grows
> every large). Sometimes columns on the fact exhibit deriving relationship
> too. Here's an example fact table:
> (dt date, seller_id bigint, seller_name varchar(100) , item_id bigint,
> item_url varchar(1000), count decimal, price decimal)
> seller_name is uniquely determined by each seller id, and item_url is
> uniquely determined by each item_id. The users does not expect to do
> filtering on columns like seller name or item_url, they just want to retrieve
> it when they do grouping/filtering on other dimensions like selller id, item
> id or even other dimensions like dt.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
