[
https://issues.apache.org/jira/browse/HBASE-15600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335434#comment-15335434
]
Nick Dimiduk commented on HBASE-15600:
--------------------------------------
I'm struggling examples to cite, but I think we've already said that LP.Coproc
APIs are quasi-exempt from our semantic-ish versioning guidelines. We want to
be a hospitable environment for extension projects like Phoenix (and Trafodion,
and..), all of which by design are monkeying in HBase guts to provide a better
user experience. I'm definitely sympathetic to the position of Phoenix having
to explain different semantics for the same feature, on the same Phoenix
release, based on which HBase version a user is running. But does that mean a
new release of HBase 1.0 would be required if Phoenix "demands" it? I'm not
sure where to draw the line on accommodation.
Yeah, sounds like a dev@ discussion is in order. I think a better understanding
of how sensitive Phoenix is to HBase patch releases, a la
[PHOENIX-2732|https://issues.apache.org/jira/browse/PHOENIX-2732?focusedCommentId=15335405&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15335405],
would help fuel this discussion.
Also [~enis], I'm curious if Phoenix v4.7.0 release runs on an HBase 1.1.x +
this patch. That will be a good indicator as to the backward-compatibility
implications of the attached. Shy of a compat report, that is.
> Add provision for adding mutations to memstore or able to write to same
> region in batchMutate coprocessor hooks
> ---------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-15600
> URL: https://issues.apache.org/jira/browse/HBASE-15600
> Project: HBase
> Issue Type: Improvement
> Reporter: Rajeshbabu Chintaguntla
> Assignee: Rajeshbabu Chintaguntla
> Labels: phoenix
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.21
>
> Attachments: HBASE-15600.patch, HBASE-15600_v1.patch,
> HBASE-15600_v2.patch, hbase-15600_v3.patch, hbase-15600_v4.patch,
> hbase-15600_v5.patch, hbase-15600_v6.patch
>
>
> As part of PHOENIX-1734 we need to write the index updates to same region
> from coprocessors but writing from batchMutate API is not allowed because of
> mvcc.
> Raised PHOENIX-2742 to discuss any alternative way to write to the same
> region directly or not but not having any proper solution there.
> Currently we have provision to write wal edits from coprocessors. We can set
> wal edits in MiniBatchOperationInProgress.
> {noformat}
> /**
> * Sets the walEdit for the operation(Mutation) at the specified position.
> * @param index
> * @param walEdit
> */
> public void setWalEdit(int index, WALEdit walEdit) {
> this.walEditsFromCoprocessors[getAbsoluteIndex(index)] = walEdit;
> }
> {noformat}
> Similarly we can allow to write mutations from coprocessors to memstore as
> well. Or else we should provide the batch mutation API allow write in batch
> mutate coprocessors.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
