[ 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