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] [Commented] (CASSANDRA-3647) Support set and map value types in CQL
Date Mon, 11 Jun 2012 12:27:45 GMT

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

Sylvain Lebresne commented on CASSANDRA-3647:
---------------------------------------------

Pushed at https://github.com/pcmanus/cassandra/commits/3647 patches for this. This pretty
much implement the syntax of Jonathan's comment above, except that literals must not be quoted.
Supported methods are:
* maps: put and discard.
* sets: add, add_all (takes n arguments) and discard.
* lits: append, append_all, prepend, prepend_all, set (to set the value at a specific index),
discard (discard an object given its value) and discard_idx (discard given the index).

The implementation for maps and set is rather straighforward. Lists are implemented as a map
of TimeUUID -> value. Prepend is supported by the trick described in the previous comments
of picking a reference time (1 january 2010 as it turns out) and using that reference minus
now as a timestamp.  The list method set, discard and discard_idx share in common that they
do a read-before-write (we read the whole list to find the TimeUUID corresponding to the element
to update; we then write that element (I don't think we need to overwrite the entire list
at all)).

Another detail worth mentioning is literals. When setting a literal we must erase the previous
list. To do so, the implementation insert a (range) tombstone at 'timestamp - 1'. This have
the unfortunate consequence that if you do 2 update with a literal in the same millisecond,
you won't end up with one or the other, but rather as a merge of both literals. I don't see
a good way how to do otherwise.

As of these patches, collections (lists/maps/sets) are limited to table definition that use
a composed PRIMARY KEY. The reason is that otherwise the underlying comparator is not a composite
one, and thus there is no way to support the collection. I very strongly think that we should
change this behavior and I've opened CASSANDRA-4329 for that. But besides this limitation,
these patches are ready for review and I've pushed a few tests those in dtests (in cql_tests.py).
                
> Support set and map value types in CQL
> --------------------------------------
>
>                 Key: CASSANDRA-3647
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3647
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>              Labels: cql
>             Fix For: 1.2
>
>
> Composite columns introduce the ability to have arbitrarily nested data in a Cassandra
row.  We should expose this through CQL.

--
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