[
https://issues.apache.org/jira/browse/CASSANDRA-6917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14039213#comment-14039213
]
Robert Stupp commented on CASSANDRA-6917:
-----------------------------------------
Such a type should also be usable in collections (set, map)
And it would be great not to copy Java enum semantics. Means: not just use an
incrementing ordinal but let the user decide how the mapping should be ; allow
spares. For example a column type like this: {{enum foo<1='foo', 3='bar',
42='baz'>}}.
To make it really complex: what about an enum that maps a ByteBuffer to a
ByteBuffer internally? This makes type definition really complicated: {{enum
foo<int, text>(1='foo', 3='bar', 42='baz')}}
It needs to be bi-directional to be usable for 4175.
> enum data type
> --------------
>
> Key: CASSANDRA-6917
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6917
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Priority: Minor
> Labels: performance
>
> It seems like it would be useful to support an enum data type, that
> automatically converts string data from the user into a fixed-width data type
> with guaranteed uniqueness across the cluster. This data would be replicated
> to all nodes for lookup, but ideally would use only the keyspace RF to
> determine nodes for coordinating quorum writes/consistency.
> This would not only permit improved local disk and inter-node network IO for
> symbology information (e.g. stock tickers, ISINs, etc), but also potentially
> for column identifiers also, which are currently stored as their full string
> representation.
> It should be possible then with later updates to propagate the enum map
> (lazily) to clients through the native protocol, reducing network IO further.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
