I have an another question. New implementation of local indexes affects both server and client parts. Wouldn't it break the compatibility between old 4.x clients and new servers? I.e. clients are creating/writing local indexes into a separate table, but on server side the index updater will try to update indexes in the user table. Shouldn't we bump the major version to avoid such incompatibility?
On Sat, Jun 11, 2016 at 7:05 PM, Andrew Purtell <andrew.purt...@gmail.com> wrote: > I'm pretty sure the HBASE-15600 change wouldn't be accepted by the branch > RM for 1.1, but that is my opinion of course, not his. I could be > surprised. With 0.98 the bar would be lower as each 0.98.x release is a > minor release as defined by the HBase compatibility policy, but even so the > suggestion makes me nervous offhand. > > > 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 > > If you're able to take that position that would be good, I think. It might > help motivate people to move up to newer versions of HBase. > > > > On Jun 8, 2016, at 9:31 PM, James Taylor <jamestay...@apache.org> wrote: > > > > 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. > >> >
