[
https://issues.apache.org/jira/browse/HBASE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13713136#comment-13713136
]
Nick Dimiduk commented on HBASE-8693:
-------------------------------------
bq. again, I think that your focus at the moment is more on the key side... and
my guess is that the struct is fine for that. but this jira is "serialization
primitives" without a "row-keys" in front... so I assume you plan to use this
stuff also for the cell values, and from what I said above... I don't see an
easy way to evolve my cell data, without rewrite every time or doing "manual"
mappings for each struct version.
You're right, this implementation is too simplistic for storing complex
entities in a Cell. You can do it, but you'll be a bit stuck as there's no
concept schema identification or of evolution. I can see how the title can be
miss-leading. OrderedBytes and HDataType are no replacement for application use
of \{protobuf,avro,thrift\}, particularly in the "entity-centric modeling"
approach with fat key-values.
> Implement extensible type API based on serialization primitives
> ---------------------------------------------------------------
>
> Key: HBASE-8693
> URL: https://issues.apache.org/jira/browse/HBASE-8693
> Project: HBase
> Issue Type: Sub-task
> Components: Client
> Reporter: Nick Dimiduk
> Assignee: Nick Dimiduk
> Fix For: 0.95.2
>
> Attachments: 0001-HBASE-8693-Extensible-data-types-API.patch,
> 0001-HBASE-8693-Extensible-data-types-API.patch,
> 0001-HBASE-8693-Extensible-data-types-API.patch,
> 0002-HBASE-8693-example-Use-DataType-API-to-build-regionN.patch,
> KijiFormattedEntityId.java
>
>
--
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
