You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Viraj Jasani (Jira)" <ji...@apache.org> on 2020/01/20 21:10:00 UTC

[jira] [Comment Edited] (HBASE-23678) Literate builder API for version management in schema

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

Viraj Jasani edited comment on HBASE-23678 at 1/20/20 9:09 PM:
---------------------------------------------------------------

Agree, the scenario provided in the description definitely should have a builder API. This seems from the context of JAVA applications using HBase client and not shell right? May be good to document this API and also provide a note for those interested on how shell can serve the same purpose by using low level schema attribute values. Sounds good?

From shell, anyways only low level schema attributes are being set directly.

 

Edit: This could be a one off case where the builder API of HColumnDescriptor/ColumnDescriptorBuilder is not going to be directly accessible from shell and only available for JAVA client right? Hope this is fine as long as we have documentation on how shell can set individual attributes to achieve the same thing that the contextual builder API is doing behind the scene.


was (Author: vjasani):
Agree, the scenario provided in the description definitely should have a builder API. This seems from the context of JAVA applications using HBase client and not shell right? May be good to document this API and also provide a note for those interested on how shell can serve the same purpose by using low level schema attribute values. Sounds good?

From shell, anyways only low level schema attributes are being set directly.

> Literate builder API for version management in schema
> -----------------------------------------------------
>
>                 Key: HBASE-23678
>                 URL: https://issues.apache.org/jira/browse/HBASE-23678
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Andrew Kyle Purtell
>            Assignee: Viraj Jasani
>            Priority: Major
>
> Lars designed the combination of VERSIONS, TTL, MIN_VERSIONS, and KEEP_DELETED_CELLS with a maximum of flexibility. There is a lot of nuance regarding their usage. Almost all combinations of these four settings make sense for some use cases (exceptions are MIN_VERSIONS > 0 without TTL, and KEEP_DELETED_CELLS=TTL without TTL). There should be a way to make the behavior with TTL easier to conceive when creating the schema. This could take the form of a literate builder API for ColumnDescriptor or an extension to an existing one. 
> Let me give you a motivating example: We may want to retain all versions for a given TTL, and then only a specific number of versions after that interval elapses. This can be achieved with VERSIONS=INT_MAX, TTL=_retention_interval_, KEEP_DELETED_CELLS=TTL, MIN_VERSIONS=_num_versions_ . This is not intuitive though because VERSIONS has been used to specify the number of versions to retain (_num_versions_ in this example) since HBase version 0.1, so this is going to be a source of confusion - I've seen it in practice. 
> A literate builder API, by way of the way we design its method names, could let a user describe more or less in speaking language how they want version retention to work, and internally the builder API could set the low level schema attributes. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)