Another factor is documentation. It's hard enough to document new features and behavior as it is, but we'd have to explain that for the *same* release, it depends on which version of HBase you're using to know how to correctly configure local indexes - sometimes you need modify the hbase-site.xml on the master and sometimes you wouldn't.
It's one thing if we're EOLing these branches, but I don't think we're at that point yet. On Wednesday, June 8, 2016, Samarth Jain <samarth.j...@gmail.com> wrote: > Considering the footprint of PHOENIX-1734, it would make development > onerous if the feature is merged only to 4.x-HBase-1.2. There is already an > overhead of having to merge patches in 4 branches. It also has the > potential of increasing the likelihood of bugs being introduced arising out > of having to handle many more merge conflicts. > > Just my 2 cents :) > > > > On Tue, Jun 7, 2016 at 8:42 AM, James Taylor <jamestay...@apache.org > <javascript:;>> wrote: > > > I don't understand why HBASE-15600 is needed if we're ok with the local > > index updates not being transactional with older versions of HBase. Why > > can't we do the htable.batch() call in ParallelWriterIndexCommitter as we > > do now? The row keys are different. If this is an issue, then we could > just > > enqueue the mutations and let them be submitted outside the row lock. We > > don't need to have the row lock. > > > > Seems to me that it could be made to work without the branches diverging > so > > radically. > > > > Thanks, > > James > > > > On Tuesday, June 7, 2016, rajeshb...@apache.org <javascript:;> < > chrajeshbab...@gmail.com <javascript:;>> > > wrote: > > > > > Hi Team, > > > > > > As you know prior to PHOENIX-1734 we are storing all local index data > in > > > separate table and colocate data and index regions. To ensure proper > > > colocation we need customer balancer, custom split and merge logic > still > > > these will not ensure 100% colocation. That's why we started working > > > PHOENIX-1734 to store local index data in separate column families in > the > > > same table to ensure 100% colocation. > > > > > > As part of PHOENIX-1734 we need to write local index udpates to same > > region > > > in preBatchMutate. When I am working with master branch(The HBase > version > > > is 1.2.x) it went smooth and I continued the development and ensure new > > > implementation of local index works properly and committed the patch to > > > master branch as well. > > > > > > But when I started porting it to other branches(HBase versions less > than > > > 1.2) I realized that write to same region is in preBatchMutate is not > > > allowed by HBase versions less than 1.2. There is a dependency of > > > HBASE-15600 to make the new local index implementation work properly > for > > > versions less than 1.2. So I am not able to port it to other branches. > I > > > will complete it once the next HBase point releases have HBASE-15600. > > > > > > Now code in master branch is not in sync with other branches but the > > local > > > indexing feature is much more stable in master branch after > PHOENIX-1734 > > so > > > I think it would be better to have PHOENIX-1734 in master branch even > > > porting it to other branches might delay till upcoming HBase releases > > > available. > > > > > > Wdyt? > > > > > > Thanks, > > > Rajeshbabu. > > > > > >
