[
https://issues.apache.org/jira/browse/GORA-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278293#comment-13278293
]
Enis Soztutar commented on GORA-138:
------------------------------------
Good stuff.
Both options seems fair. The mapping from complex types into column-store types
has come up before, and as you said each option has it's own pros and cons. So
I think, the mapping should be configurable from the mappings file. In
gora-hbase, and gora-accumulo arrays are saved as column-family:index -> value,
since no one yet implemented other options, but ideally we should allow the
user to choose the way the data is mapped back. Even in the same table, you
might want small-mid sized mostly static arrays to be serialized into one cell,
but large or more dynamic arrays into super columns / families.
Having said that, it is ok to start with one of them and commit that as
default, with a room for other mapping options in mind.
> gora-cassandra array type support
> ----------------------------------
>
> Key: GORA-138
> URL: https://issues.apache.org/jira/browse/GORA-138
> Project: Apache Gora
> Issue Type: New Feature
> Components: storage-cassandra
> Reporter: Kazuomi Kashii
>
> In order to support ARRAY in gora-cassandra, we have two scenarios as follows:
> 1) super column family like the current MAP implementation; or
> 2) single column to store all elements of ARRAY.
> Each senario has pros and cons, but I'd prefer 1) and I have implemented a
> prototype.
> 1) super column family
> ** pros
> - consistent with MAP
> - each column stores primitive type value.
> ** cons
> - ARRAY cannot be contained in RECORD or MAP.
> 2) single column
> ** pros
> - complex type such as RECORD and MAP can have ARRAY value.
> ** cons
> - large size of ARRAY requres a huge single column value.
> - difficult to implement for STRING and BYTES (variable length).
> Currently, super column is used for other complex types such as RECORD and
> MAP,
> so it is consistent to use super column for ARRAY.
> Considering this, the rule that complex type cannot have complex type value
> seems a reasonable limitation, and it makes rule simple.
> If we take 1) senario with super column family,
> I can provide a patch of my implementation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
