Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4D37E10B42 for ; Thu, 8 Aug 2013 17:07:50 +0000 (UTC) Received: (qmail 19080 invoked by uid 500); 8 Aug 2013 17:07:50 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 19042 invoked by uid 500); 8 Aug 2013 17:07:49 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 19021 invoked by uid 99); 8 Aug 2013 17:07:49 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Aug 2013 17:07:49 +0000 Date: Thu, 8 Aug 2013 17:07:49 +0000 (UTC) From: "Nick Dimiduk (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-8089) Add type support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13733695#comment-13733695 ] Nick Dimiduk commented on HBASE-8089: ------------------------------------- Hi Eli, You're right, I've left this ticket untouched while working through the initial subtasks. The order-preserving serialization is a critical component of the work. I think this is a feature that HBase absolutely must provide if there's to be any hope for interoperability. I also think the serialization format is necessary but not sufficient. An HBase that ships with an API for describing data types and implementations of a set of common definitions takes the next step in interoperability. By defining the type interface, type implementations provided by 3rd parties become pluggable -- it becomes feasible for a user to plug a type from Phoenix into their Kiji application. Systems like Phoenix, Kiji, and HCatalog are all choices for defining and managing schema. It may be the case that HBase should define the schema interfaces as well, but that's definitely beyond the scope here. But if those tools are going to interoperate, they need a common language of types with which to do so. Serialization, IMHO, is insufficient. I don't know if there's a new project to be built out of this work. I see no need to create such a thing when the needs and use are not yet proven. The introduction of types in HBase will shake things up enough as it is, let's see how people and projects use them before promoting this stuff to its own project. Yes, the serialization formats defined in HBASE-8201 are designed to be language agnostic. It's highly likely that I've missed some critical details here or there in the specification. Time will tell :) -n > Add type support > ---------------- > > Key: HBASE-8089 > URL: https://issues.apache.org/jira/browse/HBASE-8089 > Project: HBase > Issue Type: New Feature > Components: Client > Reporter: Nick Dimiduk > Assignee: Nick Dimiduk > Fix For: 0.98.0 > > Attachments: HBASE-8089-types.txt, HBASE-8089-types.txt, HBASE-8089-types.txt, HBASE-8089-types.txt, hbase data types WIP.pdf > > > This proposal outlines an improvement to HBase that provides for a set of types, above and beyond the existing "byte-bucket" strategy. This is intended to reduce user-level duplication of effort, provide better support for 3rd-party integration, and provide an overall improved experience for developers using HBase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira