[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406454#comment-13406454
]
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: 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
