[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Attachment: 1744.addendum Addendum that makes TestThriftHBaseServiceHandler immune to hanging minicluster. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, 1744.addendum, HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, 1744.addendum, HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Status: Open (was: Patch Available) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Status: Patch Available (was: Open) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Attachment: 1744-trunk.10 Patch version 10 is same as patch v9. Generated for patch testing. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Status: Open (was: Patch Available) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Status: Patch Available (was: Open) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Attachment: (was: 1744-trunk.10) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Attachment: 1744-trunk.10 Previous patch testing was blocked by broken TRUNK builds. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Status: Open (was: Patch Available) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Status: Patch Available (was: Open) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Attachment: HBASE-1744.11.patch added patch with fix so tests build against current trunk (also now using --no-prefix option in git diff) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Status: Patch Available (was: Open) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Status: Open (was: Patch Available) cancelling existing patch Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, 1744-trunk.10, HBASE-1744.11.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-1744: - Status: Patch Available (was: Open) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-1744: - Status: Open (was: Patch Available) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-1744: - Status: Patch Available (was: Open) Submitting patch to see if it breaks any unit tests. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Copeland updated HBASE-1744: Attachment: HBASE-1744.8.patch Sure -- v8 is v7 + the TDeleteType addition. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Attachment: HBASE-1744.9.patch Looks good. I added another patch which also sets TDelete to use DELETE_COLUMNS by default and added some tests. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.8.patch, HBASE-1744.9.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Copeland updated HBASE-1744: Attachment: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch Incremental patch adding TDeleteType enum Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: 0001-thrift2-enable-usage-of-.deleteColumns-for-thrift.patch, HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Status: Patch Available (was: Open) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Attachment: HBASE-1744.7.patch new patch, added licenses and trivial python demo. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.7.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Attachment: HBASE-1744.6.patch Added new patch, with a few more tests and a incomplete trivial java example. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.6.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Attachment: HBASE-1744.4.patch Added patch with Bob Copeland's fixes and updated to trunk Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Lars Francke Priority: Critical Fix For: 0.94.0 Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Assignee: Tim Sell (was: Lars Francke) Status: Patch Available (was: Open) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Status: Open (was: Patch Available) Weird. Strange it works for me, turns out I am compiling with thrift 0.6.1 and hbase is using 0.7, cancelling the patch. I'll stick a new one up in a bit. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Sell updated HBASE-1744: Attachment: HBASE-1744.5.patch Added patch which has the thrift2 generated files generated from 0.7.0, Also has a few tests. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Tim Sell Priority: Critical Fix For: 0.94.0 Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.4.patch, HBASE-1744.5.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- 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
[jira] [Updated] (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-1744: -- Fix Version/s: (was: 0.92.0) 0.94.0 There seems to be little attention to this JIRA. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Lars Francke Priority: Critical Fix For: 0.94.0 Attachments: HBASE-1744.2.patch, HBASE-1744.3.patch, HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Francke updated HBASE-1744: Attachment: HBASE-1744.preview.1.patch This adds a patch with a lot of the stuff done. I don't know of any big missing or wrong things with the new Thrift definition file except these: * I have not added filters in any form * I have not added row locks * I added a version constant for the API and set it to 2.0.0 - I thought it might be a good idea to expose a version number that shows if the API has changed and follows the regular version number rules. Haven't added a thrift method yet. Good or bad idea? * I'm not entirely sure about TDelete and the delete methods. There are so many different meanings and I haven't managed to put them all in so far. Will have to think about that again This also implements the Server part (which are mostly wrappers) and contains the beginnings of an Admin interface (I was too lazy to weed that out from this preview now). Also: Tests not done yet. Before going much further I'd love to get some general feedback on the HbaseClient.thrift and Types.thrift file. Does this API work for you or does it need changes? Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Lars Francke Priority: Critical Fix For: 0.92.0 Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Francke updated HBASE-1744: Attachment: (was: HbaseClient.thrift) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Lars Francke Priority: Critical Fix For: 0.92.0 Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Francke updated HBASE-1744: Attachment: (was: HbaseClientTypes.thrift) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Lars Francke Priority: Critical Fix For: 0.92.0 Attachments: HBASE-1744.preview.1.patch, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Francke updated HBASE-1744: Attachment: (was: Hbase.thrift) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Lars Francke Priority: Critical Fix For: 0.92.0 Attachments: thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Francke updated HBASE-1744: Attachment: HbaseClientTypes.thrift HbaseClient.thrift I've attached a draft of the new Thrift interface. I'd appreciate any input. But I probably forgot something and there are a few ToDos in there. I plan on adding a HbaseAdminClient.thrift file that extends the basic one with all the admin-y stuff (enable/disable tables etc.) Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Lars Francke Priority: Critical Fix For: 0.92.0 Attachments: HbaseClient.thrift, HbaseClientTypes.thrift, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-1744: - Fix Version/s: (was: 0.90.0) We'll make do w/ what we have. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Lars Francke Attachments: Hbase.thrift, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (HBASE-1744) Thrift server to match the new java api.
[ https://issues.apache.org/jira/browse/HBASE-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Gray updated HBASE-1744: - Priority: Critical (was: Major) Fix Version/s: 0.92.0 This is starting to get pretty critical. Putting into 0.92 and bumping prio. Thrift server to match the new java api. Key: HBASE-1744 URL: https://issues.apache.org/jira/browse/HBASE-1744 Project: HBase Issue Type: Improvement Components: thrift Reporter: Tim Sell Assignee: Lars Francke Priority: Critical Fix For: 0.92.0 Attachments: Hbase.thrift, thriftexperiment.patch This mutateRows, etc.. is a little confusing compared to the new cleaner java client. Thinking of ways to make a thrift client that is just as elegant. something like: void put(1:Bytes table, 2:TPut put) throws (1:IOError io) with: struct TColumn { 1:Bytes family, 2:Bytes qualifier, 3:i64 timestamp } struct TPut { 1:Bytes row, 2:mapTColumn, Bytes values } This creates more verbose rpc than if the columns in TPut were just mapBytes, mapBytes, Bytes, but that is harder to fit timestamps into and still be intuitive from say python. Presumably the goal of a thrift gateway is to be easy first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.