Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Sat, 8 Jun 2013 17:41:24 +0000 (UTC)
From: "Carl Yeksigian (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12601545.1344247999073.89471.1370713284140@arcas>
In-Reply-To: <JIRA.12601545.1344247999073@arcas>
References: <JIRA.12601545.1344247999073@arcas>
Subject: [jira] [Commented] (CASSANDRA-4495) Don't tie client side use of
 AbstractType to JDBC
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Carl Yeksigian commented on CASSANDRA-4495:
-------------------------------------------

Just pushed up a couple of new commits.

- Removed the o.a.c.cql.jdbc namespace
- Added getType
- Added List,Set,Map implementations
  - Haven't figured out how to merge the {List,Set,Map}Type's compose and decompose because of their usage of validate
- Added a "asCompose()" call to AbstractType which returns the AbstractComposer for each type
                
> 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