cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Yaskevich (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-3647) Support set and map value types in CQL
Date Wed, 04 Jul 2012 11:33:35 GMT


Pavel Yaskevich commented on CASSANDRA-3647:

bq. Ok fine. I don't agree (more precisely I don't think perfect OO design at all cost is
necessarily superior) but I'm not interested in that debate, at least not on that ticket.
So do you have concrete proposition for that ticket? If not, I suggest we consider it good
enough for now, and feel free to open a follow up ticket with a clean refactor that follow
OO design to the letter.

This is what I wrote in the previous ticket - 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.

bq. Now the fact is that we need a class to represent those collection literals and we need
a common ancestor to that class and the Term class. Making the literals being of class Term
(or a subclass) would be ugly because none of the method of Term apply to the (collection)
literals. But the literals also have methods that make no sense for Term (namely validateType,
isEmpty and constructFunction), so we don't want to put those methods in the interface shared
with Term either.

And why do we need the common ancestor so much if List/Set/Map don't have anything in common
with Term except those classes are it's containers?
> Support set and map value types in CQL
> --------------------------------------
>                 Key: CASSANDRA-3647
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


View raw message