About ColumnGroup feature

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

About ColumnGroup feature

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

Reply | Threaded
Open this post in threaded view
|

Re: About ColumnGroup feature

ravipesala
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
Reply | Threaded
Open this post in threaded view
|

Re: About ColumnGroup feature

Liang Chen
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
Reply | Threaded
Open this post in threaded view
|

Re: About ColumnGroup feature

Erlu Chen
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.
Reply | Threaded
Open this post in threaded view
|

RE: About ColumnGroup feature

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

Reply | Threaded
Open this post in threaded view
|

Re: About ColumnGroup feature

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