[
https://issues.apache.org/jira/browse/CASSANDRA-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182731#comment-13182731
]
Ed Anuff commented on CASSANDRA-3625:
-------------------------------------
Are the UnsupportedOperationExceptions thrown by the FixedValueComparator for
compose(), decompose(), getString(), and validate() going to cause any
problems? getString() looks like it might get called.
> Do something about DynamicCompositeType
> ---------------------------------------
>
> Key: CASSANDRA-3625
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3625
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Sylvain Lebresne
> Attachments: 0001-allow-comparing-different-types.patch
>
>
> Currently, DynamicCompositeType is a super dangerous type. We cannot leave it
> that way or people will get hurt.
> Let's recall that DynamicCompositeType allows composite column names without
> any limitation on what each component type can be. It was added to basically
> allow to use different rows of the same column family to each store a
> different index. So for instance you would have:
> {noformat}
> index1: {
> "bar":24 -> someval
> "bar":42 -> someval
> "foo":12 -> someval
> ...
> }
> index2: {
> 0:uuid1:3.2 -> someval
> 1:uuid2:2.2 -> someval
> ...
> }
> ....
> {noformat}
> where index1, index2, ... are rows.
> So each row have columns whose names have similar structure (so they can be
> compared), but between rows the structure can be different (we neve compare
> two columns from two different rows).
> But the problem is the following: what happens if in the index1 row above,
> you insert a column whose name is 0:uuid1 ? There is no really meaningful way
> to compare "bar":24 and 0:uuid1. The current implementation of
> DynamicCompositeType, when confronted with this, says that it is a user error
> and throw a MarshalException.
> The problem with that is that the exception is not throw at insert time, and
> it *cannot* be because of the dynamic nature of the comparator. But that
> means that if you do insert the wrong column in the wrong row, you end up
> *corrupting* a sstable.
> It is too dangerous a behavior. And it's probably made worst by the fact that
> some people probably think that DynamicCompositeType should be superior to
> CompositeType since you know, it's dynamic.
> One solution to that problem could be to decide of some random (but
> predictable) order between two incomparable component. For example we could
> design that IntType < LongType < StringType ...
> Note that even if we do that, I would suggest renaming the
> DynamicCompositeType to something that suggest that CompositeType is always
> preferable to DynamicCompositeType unless you're really doing very advanced
> stuffs.
> Opinions?
--
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
