[
https://issues.apache.org/jira/browse/CASSANDRA-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14199487#comment-14199487
]
Tyler Hobbs commented on CASSANDRA-7859:
----------------------------------------
bq. It needs a minor rebase
Merged the latest 2.1 (changes are on the same branch)
bq. SelectStatement.getRequestedColumns still has the unrelated code. Haven't
really reviewed it so would be nice to pull it out for some other ticket.
So, the problem had to do with multi-column {{IN}} queries on {{COMPACT
STORAGE}} tables. I started CASSANDRA-8264 for this, but with those changes
reversed, there are test failures in FrozenCollectionsTest. As described in
8264, it looks like there are some additional problems with {{COMPACT STORAGE}}
and multi-column relations that are not resolved by this ticket. Would you
prefer committing the current changes and doing the rest in 8264, or committing
this with with the getRequestedColumns changes reversed and fixing it all
together in 8264?
bq. I kind of like the idea of shortening fullcollection to full, let's do that
(unless someone else chime in with a better suggestion).
Done
bq. I don't think we need CollectionType.isValidCompatibleWithInternal at all
since it's equivalent to isCompatibleWith.
That's not actually true for frozen lists and maps. When frozen lists and maps
are used as cell values, the collection value ordering doesn't matter.
However, while thinking about this I realized the original implementation
wasn't exactly correct, so there are a couple of new commits in the branch that
fix this. Basically, the nameComparator and valueComparator shouldn't be used
for frozen collections, since they are directly compared with {{elements}} and
{{keys}}/{{values}} for maps.
bq. We could now add a assert !isMultiCell in the collections compare() method.
That's true, but I think it could potentially introduce assertion errors when
the behavior is reasonable. For example, suppose a list of IN values are being
sorted for a (non-frozen) collection column; it would be natural to use the
non-frozen CollectionType instance's {{compare()}} for sorting. To avoid
making that fail (probably unexpectedly), I would prefer not to add an assert.
> Extend freezing to collections
> ------------------------------
>
> Key: CASSANDRA-7859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7859
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Tyler Hobbs
> Labels: cql
> Fix For: 2.1.2
>
> Attachments: 7859-v1.txt
>
>
> This is the follow-up to CASSANDRA-7857, to extend {{frozen}} to collections.
> This will allow things like {{map<text, frozen<map<int, int>>>}} for
> instance, as well as allowing {{frozen}} collections in PK columns.
> Additionally (and that's alsmot a separate ticket but I figured we can start
> discussing it here), we could decide that tuple is a frozen type by default.
> This means that we would allow {{tuple<int, text>}} without needing to add
> {{frozen}}, but we would require {{frozen}} for complex type inside tuple, so
> {{tuple<int, list<text>>}} would be rejected, but not {{tuple<int,
> frozen<list<text>>>}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
