[
https://issues.apache.org/jira/browse/CASSANDRA-3647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13405943#comment-13405943
]
Pavel Yaskevich commented on CASSANDRA-3647:
--------------------------------------------
bq. I don't know actually. That's definitively an option but on the other side
I wonder what that would really get us. I know instanceof has bad reputation,
and I certainly agree that we shouldn't overuse it, but I don't think we should
avoid it at all cost either. In most instanceof usage for CollectionType and
CompositeType, a cast follows (and in most case I don't see how to refactor to
avoid those casts without being uber ugly, though I'm open to suggestion), and
if your going to cast, I think testing with instanceof is actually safer than
using a boolean method.
This is the main problem on my opinion - that we need a casts/instanceof checks
which is a chronic problem of type hierarchy of o.a.c.db.marshal package
related to Composite and Collection types, I think we should reflect their most
commonly used functionality in AbstractType.
bq. If I understand correctly those are related. I've refactored Value.java and
UpdateStatement a bit to merge the code dealing with the different literals. It
does not eliminate all the instanceof and casts, but I think the remaining one
are ok (that is, I don't see a clearly better way to do the same thing without
the instanceof).
I like what you did there, how about we go further and move
validateType(CFDefinition.Name) and constructionFunction() to Value and remove
(or rename Value to) Literal as all of the classes implement only that one
interface, so it would be someting like Literal.{List, Set, Map} and you would
be able to "assert instance of Literal" in UpdateStatement?...
bq. "definition" should be "definitions"
There are couple of same typos in the UpdateStatement left - lines _341_, _349_
and _373_
bq. UpdateStatement "mutationForKey" method - do we need to enforce using
"group" as a last parameter all the time, even when we set it to "null" ?
That was fixed in the last commits so no problem.
bq. CollectionType line 89 ListType line 147 "argument" should be "arguments"
That seems to be removed too, sorry, I have seen they in a first commits.
> 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
