[ https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406474#comment-13406474 ]
Sylvain Lebresne commented on CASSANDRA-3647: --------------------------------------------- bq. If the most common thing we do after cast with CompositeType is get "types" field then we could add Collection<AbstractType<?>> getComponentTypes() method So 100% of the time, when we access the "types" field the code is specific to compositeType, so we would still have to test if the type is composite and we would never call the getComponentTypes for non-composite type. Hence the only thing that would change is that we would replace "if (type instanceof CompositeType)" by "if (type.isCompositeType())" and "((CompositeType)type).types" by "type.getComponentTypes()" which is imho *exactly* the same thing (allergic reaction to instanceof/casts put aside). Except that in the meantime you'll have polluted the interface of AbstractType with 2 new methods. And it is less safe because if someone writes a custom type that happens to change the implementation of those methods, it will almost surely be a bug. So I'm not convinced at all by that idea. But don't get me wrong, if I were to redesign C* from the ground up, I would probably make composite a more "native" notion and everything would be a composite (with potentially only 1 component) and composites wouldn't be a subclass of AbstractType at all. But this is not really an option, at least not on the short term. On a more general "design" level, in the current code, an AbstractType in general don't have "components types" so I don't think we should add a getComponentTypes() method. But since all that has nothing to do with this ticket, if you think it would be a good idea, I can only encourage you to open a separate ticket on which we could have a more focused discussion. bq. And why do we need the common ancestor Because we want Operation.Set and 'List<Value> columnValues' in UpdateStatement to be able to contain both Term and collection Literal (i.e. Value is a marker interface basically). bq. List/Set/Map don't have anything in common with Term That's not what I said. And in fact Value defines the asList() method that both Term and List/Set/Map implement. What I said is that List/Set/Map also have most of their methods that don't apply to Term and Term have most of his method that don't apply to List/Set/Map. Having the intersection non-empty don't mean one is contain in the other. Note that I'm not saying it's the only design. We probably could duplicate Operation.Set to have one applying to Term and one applying to collection literals and split UpdateStatement.columnValues into two lists, but imho having the Value interface to avoid the code duplication is cleaner. > 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