[
https://issues.apache.org/jira/browse/HBASE-22385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16837681#comment-16837681
]
Nick Dimiduk commented on HBASE-22385:
--------------------------------------
Maybe you guys could unpack some of your discussion on the dev list? It sounds
to me like what you want is a CellSource interface. I’m not sure why you’d want
to sérialité such a class name into a persisted location, but I bet all will be
made clear on your discuss thread :)
> Consider "programmatic" HFiles
> ------------------------------
>
> Key: HBASE-22385
> URL: https://issues.apache.org/jira/browse/HBASE-22385
> Project: HBase
> Issue Type: Brainstorming
> Reporter: Lars Hofhansl
> Priority: Major
>
> For various use cases (among others there is mass deletes) it would be great
> if HBase had a mechanism for programmatic HFiles. I.e. HFiles (Reader) that
> produce KeyValues just like any other old HFile, but the key values produced
> are generated or produced by some other means rather than being physically
> read from some storage medium.
> In fact this could be a generalization for the various HFiles we have:
> (Normal) HFiles, HFileLinks, HalfStoreFiles, etc.
> A simple way could be to allow for storing a classname into the HFile. Upon
> reading the HFile HBase would instantiate an instance of that class and that
> instance is responsible for all further interaction with that HFile. For
> normal HFiles it would just be the normal HFileReaderVx. For that we'd also
> need to StoreFile.Reader into an interface (or a more basic base class) that
> can be properly implemented.
> (Remember this is Brainstorming :) )
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
