[
https://issues.apache.org/jira/browse/CASSANDRA-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170402#comment-13170402
]
Sylvain Lebresne commented on CASSANDRA-3625:
---------------------------------------------
bq. Right, but I thought we were positing that You Shouldn't Do That. In which
case as long as it doesn't crash, I'm good
Without going in the debate of how useful or not that is, I think that as soon
as it is allowed (to mix in the same row column with components of different
types), some will do it, so we'd rather choose the more "coherent" solution and
so I also prefer fixing some order on the types themselves and use that.
As for picking the actual sort between types, I'd prefer avoiding a hash as
it's not a very good uses for hash imo (I don't want to bother about collision,
as unlikely as it is). But using the alias character (and falling back to good
old string comparison on the class name if there is no alias) seems fine to me.
bq. Sylvain, are you working on this one or would you like me to take a stab at
it?
I haven't started writing anything so feel free to give it a shot.
> 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
>
> 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
