cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris Yen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-3625) Do something about DynamicCompositeType
Date Thu, 15 Dec 2011 09:08:30 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170057#comment-13170057
] 

Boris Yen commented on CASSANDRA-3625:
--------------------------------------

Not sure if this is doable or has an issue. 

I am thinking why not mimic that way the secondary index is implemented right now. Create
one extra column family for keeping track of the comparators for each row. So, whenever a
column is inserted to the cassandra, the cassandra needs to read before write to make sure
the new column is valid. This would sacrifice the write performance of dynamicComposite column
family, but at least it allows the cassandra to perform the validation before the actual write.
                
> 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

        

Mime
View raw message