[
https://issues.apache.org/jira/browse/CASSANDRA-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15278429#comment-15278429
]
Sylvain Lebresne commented on CASSANDRA-7826:
---------------------------------------------
bq. there's also the question if we would like to support arbitrary updates or
deletes right away, too. That would require new syntax for selecting the path
for update or delete (maybe something like mymap\['a'\]\['b'\]\[1\]
You're right, we'll need some new syntax here. But as to what we support, I'd
say we can support the easily doable extensions of what we already support to
any level of nestedness using square brackets. So if {{m}} is a {{map<text,
map<text, set<int>>>}}, we'd support:
{noformat}
* m = { 'foo' : { 'bar' : { 2, 3 } } } and m = m + { 'foo' : { 'bar' : { 2, 3 }
} };
* m['foo'] = { 'bar' : { 2, 3 } } and m['foo'] = m['foo'] + { 'bar' : { 2, 3 }
};
* m['foo']['bar'] = {2, 3}, m['foo']['bar'] = m['foo']['bar'] + {1} and
m['foo']['bar'] = m['foo']['bar'] - {1}.
{noformat}
But as we currently have no way to delete a range of complex cells, we can only
allow deleting elements in the most nested collection. Which is a bit annoying
but adding range tombstone of complex cells is definitvely a follow-up ticket
on its own imo.
bq. Also, BufferCell/tombstone can most likely handle deletes as they are,
without slices, as we'll always know at least the partial path, but if I
understand it correctly, it will require additional logic for discarding
columns whose partial path matches the path of the tombstone.
I'm not entirely sure to follow. Are you suggesting to use a partial
{{CellPath}} to implement deletion of a slice of complex cells?. If so, I
suppose that's an option, but as said above, it's definitively something I
would leave to a follow up ticket.
bq. most likely 7396 will land before this patch, so it we might have to add
support for selecting individual parts on arbitrary level (or just on the top
level at first and leave the rest for the next iterations). So the question is
what we'd like to have on the current step.
I would agree that it probably make more sense to finish/commit CASSANDRA-7396
first and rebasing this on top of it. Which does mean we'll have to think about
sub-selections. That said, I suspect the existing {{ColumnSubSelection}} should
be up to the task, aren't they? But if it's simpler to only support top level
only at first and leave the rest to a followup, I personally won't mind.
bq. Non-frozen Set and List can be nested arbitrarily deep within the map,
although nothing can be nested within Set or List.
Sgtm.
bq. At this particular moment I'm not entirely certain about the slices of keys
for maps.
That can definitively be left to a follow-up ticket, assuming we even want to
bother with it.
> support non-frozen, nested collections
> --------------------------------------
>
> Key: CASSANDRA-7826
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7826
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
> Reporter: Tupshin Harper
> Assignee: Alex Petrov
> Labels: ponies
> Fix For: 3.x
>
>
> The inability to nest collections is one of the bigger data modelling
> limitations we have right now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
