Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 2 Mar 2013 09:51:13 +0000 (UTC)
From: "Enis Soztutar (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12634957.1362194173540.369690.1362217873485@arcas>
In-Reply-To: <JIRA.12634957.1362194173540@arcas>
References: <JIRA.12634957.1362194173540@arcas>
Subject: [jira] [Commented] (HBASE-7978) Merge hbase-prefixtree into
 hbase-server
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-7978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13591382#comment-13591382 ] 

Enis Soztutar commented on HBASE-7978:
--------------------------------------

bq. Can you cite some literature supporting the above view ?
Importing hadoop trunk into eclipse... Do you need more? 
bq. I'm confused about the issue title Enis - why merge to hbase-server when it will immediately go in hbase-storage?
The title states what can be done in this issue. hbase-storage is a longer term goal, which might or might not happen later on. If it happens, we can just move the code there with the rest of the storage stuff. 
bq. In my mind it was something like hbase-codec. In fact, the prefix-tree code is nested in a package called o.a.h.h.codec, as is Stack's RPC serialization code. The idea being that hbase-common contains interfaces for different things that get encoded as opaque byte arrays, such as data blocks, bloom blocks, index blocks, rpc chunks, etc
My understanding of the current DBE is that it is not suitable to be used outside an HFile block setting. I agree that we should extend these to support encoding bulks of cells, no matter the context (rpc, hfile, etc). I would be fine if we do a codec module, if we include all of the codecs, but -1 for having a module per codec type. We also need some sanity to be able to browse the code from IDE. Also, for generating hfiles for bulk load, then you have to dynamically link that appropriate codec jar into your mapreduce job, which is not a thing we would want.
The question here is whether to rename the current module to hbase-codec and have the rest there? How close are we do extract the DBE as generic codecs? 


> Merge hbase-prefixtree into hbase-server
> ----------------------------------------
>
>                 Key: HBASE-7978
>                 URL: https://issues.apache.org/jira/browse/HBASE-7978
>             Project: HBase
>          Issue Type: Improvement
>          Components: HFile
>    Affects Versions: 0.95.0, 0.98.0
>            Reporter: Enis Soztutar
>
> I would like to discuss the possibility of merging the prefix tree module into the hbase-server module. 
> Ideally, I think we should have hbase-mapreduce and hbase-storage modules, the latter one containing most of HFile code. hbase-mapreduce depends on hbase-storage so that it knows how to encode hfiles. prefix-tree belongs to hbase-storage. 
> prefix tree is just another DBE, although a big one, and it rightfully belongs with her sisters. The fact that the code is independent from the rest of the code base does not mean that it should have it's own module. We should keep the number of modules manageable, and stay away from hadoop trunk's one-module-per-package policy. 
> Related: HBASE-7936

--
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