[
https://issues.apache.org/jira/browse/HBASE-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224951#comment-13224951
]
Phabricator commented on HBASE-5515:
------------------------------------
jyates has commented on the revision "HBASE-5515 [jira] Add a processRow API
that supports atomic multiple reads and writes on a row".
Still seems a bit bloated. I don't know what we really get from having the
RowProcessor _not_ be an endpoint in itself. A lot of the work here could be
handled by just having an abstract class that implements CoprocessorEndpoint
and is subclasses by actual RowProcessor implementations. This would also help
keep the API more condensed. More thoughts inline on how that would work.
Otherwise, seems solid.
INLINE COMMENTS
src/main/java/org/apache/hadoop/hbase/coprocessor/ProcessRowEndpoint.java:34
This whole process seems a bit roundabout. You make an endpoint that then takes
the writable which immediately then just calls the hregion to process that
processor.... have to agree with Lars that the endpoint should in fact just be
the rowProcesssor - you would have the FriendsOfFriendsProcessor just be a
coprocessor that you turn on for your table.
src/main/java/org/apache/hadoop/hbase/coprocessor/ProcessRowEndpoint.java:52
If you wanted to make it easier for people to implement their own multi-action
processing, then (going back to my comment above) you can make the
RowProcessorEnpoint just have an abstract method that people use to implement
their own processing.
This abstract method would actually be called inside of the 'process' method
that would take care of getting the row lock, etc and leaving just the
processing for the actual implementation (which could return an iterable) and
then push them back to the back.
Some work would be involved in this approach, but it would be easily
extractable into the stuff from HBASE-5529
src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:4303 This
seems like a lot of copying from other parts in the code - maybe it can be
abstracted out? This might be something for the next patch for the
MultiRowProcessor stuff
REVISION DETAIL
https://reviews.facebook.net/D2067
> Add a processRow API that supports atomic multiple reads and writes on a row
> ----------------------------------------------------------------------------
>
> Key: HBASE-5515
> URL: https://issues.apache.org/jira/browse/HBASE-5515
> Project: HBase
> Issue Type: New Feature
> Reporter: Scott Chen
> Assignee: Scott Chen
> Attachments: HBASE-5515.D2067.1.patch, HBASE-5515.D2067.10.patch,
> HBASE-5515.D2067.11.patch, HBASE-5515.D2067.12.patch,
> HBASE-5515.D2067.13.patch, HBASE-5515.D2067.14.patch,
> HBASE-5515.D2067.15.patch, HBASE-5515.D2067.16.patch,
> HBASE-5515.D2067.17.patch, HBASE-5515.D2067.18.patch,
> HBASE-5515.D2067.19.patch, HBASE-5515.D2067.2.patch,
> HBASE-5515.D2067.3.patch, HBASE-5515.D2067.4.patch, HBASE-5515.D2067.5.patch,
> HBASE-5515.D2067.6.patch, HBASE-5515.D2067.7.patch, HBASE-5515.D2067.8.patch,
> HBASE-5515.D2067.9.patch
>
>
> We have modified HRegion.java internally to do some atomic row processing. It
> will be nice to have a plugable API for this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
