cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4495) Don't tie client side use of AbstractType to JDBC
Date Tue, 18 Jun 2013 14:17:25 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686761#comment-13686761
] 

Sylvain Lebresne commented on CASSANDRA-4495:
---------------------------------------------

Haven't really look at the detail of the patch, but for what it's worth, I've somehow never
been a fan of the compose/decompose terminology. I'd prefer say encode/decode or serialize/deserialize.
And BooleanCodec or BooleanSerializer sounds better to my hear than BooleanComposer. But do
feel free to discard that opinion if it's just me being french and if composer sounds perfectly
fine to you guys.
                
> 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, 4495-v2.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

Mime
View raw message