cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Yaskevich (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-3647) Support set and map value types in CQL
Date Mon, 02 Jul 2012 16:53:24 GMT

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

Pavel Yaskevich edited comment on CASSANDRA-3647 at 7/2/12 4:52 PM:
--------------------------------------------------------------------

Here is my comments/questions after code review:

- *AbstractType* Wouldn't it be a good idea to add a "boolean isCollectionType()" method which
by default would return "false"? That would allow to avoid "instanceof" checks which are done
all over the place. It's probably time to do the same for CompositeType as we get more and
more instanceof checks for it as well.

- *TypeParser* method "stringifyCollectionsParameters" - The following is not DRY as the same
actions repeated in all clauses, when to append(',') could be distinguished with a condition
instead of code duplication.

- *Value* I think we should add a way to distinguish between different types of values without
using "instanceof" all them. In combination with common iteration method (asList() from the
last patch) for all of them that would allow to remove "instanceof" checks and "cast" everywhere.

- *UpdateStatement* starting from line _199_ - only difference between "instanceof" cases
is pre-validation which could be added to the separate method in Value for example and "addMutation"
call with different types this also proves previous point about Value.

- *UpdateStatement* "mutationForKey" method - do we need to enforce using "group" as a last
parameter all the time, even when we set it to "null" ?

- *UpdateStatement* line _407_ "definition" should be "definitions"

- *CollectionType* line _89_ *ListType* line _147_ "argument" should be "arguments" 


                
      was (Author: xedin):
    Here is my comments/questions after code review:

# *AbstractType* Wouldn't it be a good idea to add a "boolean isCollectionType()" method which
by default would return "false"? That would allow to avoid "instanceof" checks which are done
all over the place. It's probably time to do the same for CompositeType as we get more and
more instanceof checks for it as well.

# *TypeParser* method "stringifyCollectionsParameters" - The following is not DRY as the same
actions repeated in all clauses, when to append(',') could be distinguished with a condition
instead of code duplication.

# *Value* I think we should add a way to distinguish between different types of values without
using "instanceof" all them. In combination with common iteration method (asList() from the
last patch) for all of them that would allow to remove "instanceof" checks and "cast" everywhere.

# *UpdateStatement* starting from line _199_ - only difference between "instanceof" cases
is pre-validation which could be added to the separate method in Value for example and "addMutation"
call with different types this also proves previous point about Value.

# *UpdateStatement* "mutationForKey" method - do we need to enforce using "group" as a last
parameter all the time, even when we set it to "null" ?

# *UpdateStatement* line _407_ "definition" should be "definitions"

# *CollectionType* line _89_ *ListType* line _147_ "argument" should be "arguments" 


                  
> 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