You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Rick Shaw (JIRA)" <ji...@apache.org> on 2013/06/05 23:39:22 UTC
[jira] [Comment Edited] (CASSANDRA-4495) Don't tie client side use
of AbstractType to JDBC
[ https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13676376#comment-13676376 ]
Rick Shaw edited comment on CASSANDRA-4495 at 6/5/13 9:38 PM:
--------------------------------------------------------------
Could this solution be enhanced to address the collection types? (List, Set, and Map). This is really awkward to do on the client side.
{{getType()}} in each class would also be handy when you are passed the AbstractType.
Is there a reason you did not remove the {{o.a.c.cql.jdbc}} package from the build?
Great job BTW...
was (Author: ardot):
Could this solution be enhanced to address the collection types? (List, Set, and Map). This is really awkward to do on the client side.
{{getType()}} in each class would also be handy when you are passed the AbstractType.
Is there a reason you did not remove the {{o.a.c.cql.jdbc}} package from the build?
> 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