Re: [DISCUSSION] About data backward compatibility

2017-08-17 Thread Erlu Chen
Agree with caolu, I think users may be confused by lots of format. In the future, it will be better for carbon to unify the data format. The unified format should compatible with previous format. If it is unavoidable to give different format to support different use case to gain better performance

Re: [DISCUSSION] About data backward compatibility

2017-08-15 Thread bill.zhou
hi Jacky & Ravindra I think it should make sure the migration tool performance is good then can chose option 2. like some user already use v1 for 1 year, there are 1 year history data, the Migration tool should be make sure the high performance. following is my thinking the key feature should

Re: [DISCUSSION] About data backward compatibility

2017-08-14 Thread Lu Cao
+1 Option2 is better. Multiple formats will make user and developer confuse, should integrate ASAP. On Tue, Aug 15, 2017 at 10:18 AM, David CaiQiang wrote: > I agree with Ravindra, now is the time to implement migration tool. > > > > - > Best Regards > David Cai > -- > View this message in c

Re: [DISCUSSION] About data backward compatibility

2017-08-14 Thread David CaiQiang
I agree with Ravindra, now is the time to implement migration tool. - Best Regards David Cai -- View this message in context: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/DISCUSSION-About-data-backward-compatibility-tp20183p20219.html Sent from the Apache CarbonDa

Re: [DISCUSSION] About data backward compatibility

2017-08-12 Thread Ravindra Pesala
Hi Jacky, I feel option 2 is better but it should have one time migration of data from old formats to latest format. So first we should have migration tool support to read old format data using the old version and write using the latest version. This migration should be capable of supporting any o