Hi Community,
In JIRA 1014, we are adding Unsafe ColumnPage in data load process to reduce GC, and adding EncodingStrategy for Encoding Overriding features to make open up encoding interface for both usability and extensibility. When implementing these new features, I found ColumnGroup feature creates unnecessary burden on data loading code and makes developer interfaces more complex to use. For example, since ColumnGroup can appear in any field in the table, even in SORT_COLUMNS, it forces developer to understand ColumnGroup concept and handle it in its encoding implementation. As far as I know, there is not much discussion on ColumnGroup in the mail list and I think it is high possibility that no one is using it. So I am proposing to remove this feature and it can enable carbon to make Encoding interface cleaner for developers. Please vote: A. Remove it B. Not remove it, and provide reason Thanks, Jacky Li |
Hi,
+1 for A (removal of Column group feature.) Column group is anyway was not tuned well and it needs lot of effort to get the good performance. And it is also unused feature in community as far as I know. It becomes bottle neck to add new features on carbon data. So it is better to remove the unused features to keep the system clean. Regards, Ravindra. On 10 June 2017 at 06:35, Jacky Li <[hidden email]> wrote: > Hi Community, > > In JIRA 1014, we are adding Unsafe ColumnPage in data load process to > reduce GC, and adding EncodingStrategy for Encoding Overriding features to > make open up encoding interface for both usability and extensibility. > > When implementing these new features, I found ColumnGroup feature creates > unnecessary burden on data loading code and makes developer interfaces more > complex to use. For example, since ColumnGroup can appear in any field in > the table, even in SORT_COLUMNS, it forces developer to understand > ColumnGroup concept and handle it in its encoding implementation. > > As far as I know, there is not much discussion on ColumnGroup in the mail > list and I think it is high possibility that no one is using it. So I am > proposing to remove this feature and it can enable carbon to make Encoding > interface cleaner for developers. > > Please vote: > A. Remove it > B. Not remove it, and provide reason > > > Thanks, > Jacky Li > > -- Thanks & Regards, Ravi |
Administrator
|
In reply to this post by Jacky Li
Hi
+1 for removal ColumnGroup. it would be helpful to simplify the current system code. Regards Liang |
In reply to this post by Jacky Li
Hi
+ 1 for A (Remove ColumnGroup feature). If few user uses this feature and it brings unnecessary burden when implement other feature. I alse suggest remove it which do more harm than good. Regards. Chenerlu. |
In reply to this post by Jacky Li
not a feature beneficial to real-world application, vote for A!
Jihong -----Original Message----- From: Jacky Li [mailto:[hidden email]] Sent: Friday, June 09, 2017 6:05 PM To: [hidden email] Subject: About ColumnGroup feature Hi Community, In JIRA 1014, we are adding Unsafe ColumnPage in data load process to reduce GC, and adding EncodingStrategy for Encoding Overriding features to make open up encoding interface for both usability and extensibility. When implementing these new features, I found ColumnGroup feature creates unnecessary burden on data loading code and makes developer interfaces more complex to use. For example, since ColumnGroup can appear in any field in the table, even in SORT_COLUMNS, it forces developer to understand ColumnGroup concept and handle it in its encoding implementation. As far as I know, there is not much discussion on ColumnGroup in the mail list and I think it is high possibility that no one is using it. So I am proposing to remove this feature and it can enable carbon to make Encoding interface cleaner for developers. Please vote: A. Remove it B. Not remove it, and provide reason Thanks, Jacky Li |
In reply to this post by Jacky Li
+1 for A
As I known, so far ColumnGroup feature can't improve performance very well, it became a useless feature nearly. If necessary, we need redesign this feature to keep code clean and tune it well to improve performance.
Best Regards
David Cai |
Free forum by Nabble | Edit this page |