cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CASSANDRA-4988) Fix concurrent addition of collection columns
Date Mon, 03 Mar 2014 10:03:28 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-4988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne resolved CASSANDRA-4988.
-----------------------------------------

       Resolution: Duplicate
    Fix Version/s:     (was: 2.0.6)

As said above, there is not real way we can make this happen in a minor release, and the right
solution is basically a sub-part of CASSANDRA-6717, so marking this as a duplicate of that
latter issue.

> Fix concurrent addition of collection columns
> ---------------------------------------------
>
>                 Key: CASSANDRA-4988
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4988
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>
> It is currently not safe to update the schema by adding multiple collection columns to
the same table. The reason is that with collections, the comparator embeds a map of names->comparator
for each collection columns (since different maps can have different key type for example).
And when serialized on disk in the schema table, the comparator is serialized as a string
with that map as one column. So if new collection columns are added concurrently, the addition
may not be merged correctly.
> One option to fix this would be to stop serializing the names->comparator map of ColumnToCollectionType
in toString(), and do one of:
> # reconstruct that map from the information stores in the schema_columns. The downside
I can see is that code-wise this may not be super clean to do.
> # change ColumnToCollectionType so that instead of having it's own names->comparator
map, to just store a point to the CFMetaData that contains it and when it needs to find the
exact comparator for a collection column, it would use CFMetadata.column_metadata directly.
The downside is that creating a dependency from a comparator to a CFMetadata feels a bit backward.
> Note sure what's the best solution of the two honestly.
> While probably more anecdotal, we also now allow to change the type of the comparator
in some cases (for example updating to BytesType is always allowed), and doing so concurrently
on multiple components of a composite comparator is also not safe for a similar reason. I'm
not sure how to fix that one.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message