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 Wed, 04 Jul 2012 10:36:34 GMT

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

Pavel Yaskevich edited comment on CASSANDRA-3647 at 7/4/12 10:35 AM:
---------------------------------------------------------------------

bq. We test 6 times for "instanceof CollectionType": one time is to call serializeForThrift()
and 2 other times are to call the execute() methods...

I wouldn't actually judge this by *current* usages of instanceof/casts because what they show
bad tendency where users are forced to use downcasts to get things which are natural to the
complex types but not reflected in the common AbstractType interface. Every time instanceof
is used it indicates that components' OO design is broken. 

If the most common thing we do after cast with CompositeType is get "types" field then we
could add Collection<AbstractType<?>> getComponentTypes() method. Simple types
would return just one component - themselves (or throw an exception saying that type is not
complex to be sure that method is not misused) and complex ones would be able to return immutable
list of their component types, in combination with isComposite() method that would eliminate
instanceof/downcasts completely. 

I don't currently clearly see how to be with CollectionType.execute{Function} methods but
I will think about it.

bq. We cannot do that because Term implements Value. The point of Value is to be a Term or
a Literal.

That means that you are confusing semantics of the "literal" e.g. https://en.wikipedia.org/wiki/Literal_(computer_programming)
, so Term actually should become {Unary | Single}Literal and implement Literal where {List,
Set, Map} classes would have UnaryLiteral as base element, there is no need to invent hierarchy
like Value.Literal just to make it fit with current Term implementation.  
                
      was (Author: xedin):
    bq. We test 6 times for "instanceof CollectionType": one time is to call serializeForThrift()
and 2 other times are to call the execute() methods...

I wouldn't actually judge this by *current* usages of instanceof/casts because what they show
bad tendency where users are forced to use downcasts to get things which are natural to the
complex types but not reflected in the common AbstractType interface. Every time instanceof
is used it indicates that components' OO design is broken. 

If the most common thing we do after cast with CompositeType is get "types" field then we
could add Collection<AbstractType<?>> getComponentTypes() method. Simple types
would return just one component - themselves and complex ones would be able to return immutable
list of their component types, in combination with isComposite() method that would eliminate
instanceof/downcasts completely. 

I don't currently clearly see how to be with CollectionType.execute{Function} methods but
I will think about it.

bq. We cannot do that because Term implements Value. The point of Value is to be a Term or
a Literal.

That means that you are confusing semantics of the "literal" e.g. https://en.wikipedia.org/wiki/Literal_(computer_programming)
, so Term actually should become {Unary | Single}Literal and implement Literal where {List,
Set, Map} classes would have UnaryLiteral as base element, there is no need to invent hierarchy
like Value.Literal just to make it fit with current Term implementation.  
                  
> 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