[
https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684002#comment-13684002
]
Carl Yeksigian commented on CASSANDRA-4495:
-------------------------------------------
This adds validate to the composer.
A couple of things to be aware of:
- Replaced o.a.c.db.marshal.MarshalException with o.a.c.types.MarshalException
as it may be thrown to a client
- Collection composer validate no ops, reasoning below
I'm not sure that there is any reason to validate the Collections. It seems
that the previous validation would fail on, for example, Map<Map<TimeUUID,
string>, TimeUUID>, as the validation of a Map is actually validating using the
Value type of the Map, rather than iterating through the values and making sure
that an entry is valid. This entry-wise validation happens when we call compose.
> Don't tie client side use of AbstractType to JDBC
> -------------------------------------------------
>
> Key: CASSANDRA-4495
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4495
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Carl Yeksigian
> Priority: Minor
> Fix For: 2.0
>
> Attachments: 4495.patch
>
>
> We currently expose the AbstractType to java clients that want to reuse them
> though the cql.jdbc.* classes. I think this shouldn't be tied to the JDBC
> standard. JDBC was make for SQL DB, which Cassandra is not (CQL is not SQL
> and will never be). Typically, there is a fair amount of the JDBC standard
> that cannot be implemented with C*, and there is a number of specificity of
> C* that are not in JDBC (typically the set and maps collections).
> So I propose to extract simple type classes with just a compose and decompose
> method (but without ties to jdbc, which would allow all the jdbc specific
> method those types have) in the purpose of exporting that in a separate jar
> for clients (we could put that in a org.apache.cassandra.type package for
> instance). We could then deprecate the jdbc classes with basically the same
> schedule than CQL2.
> Let me note that this is *not* saying there shouldn't be a JDBC driver for
> Cassandra.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
