cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Shaw (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-2478) Custom CQL protocol/transport
Date Tue, 22 May 2012 17:43:42 GMT

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

Rick Shaw edited comment on CASSANDRA-2478 at 5/22/12 5:42 PM:
---------------------------------------------------------------

re: KS/CF metadata. As you say, JDBC/SQL can have resultset information from many tables,
which is why you can acquire that metadata information at the column level. The {{ResultSetMetaData}}
interface provides methods for {{getSchemaName(column)}} and {{getTableName(column)}} on a
column-by-column basis. The point is tools use these interfaces and methods heavily to deliver
their functionality and we will improve adoption of the Server and the Driver if we can make
the interface process for these tools deliver as much information as practical.
                
      was (Author: ardot):
    re: KS/CF meetadata. As you say, JDBC/SQL can have resultset information from many tables,
which is why you can acquire that metadata information at the column level. The {{ResultSetMetaData}}
interface provides methods for {{getSchemaName(column)}} and {{getTableName}} on a column
by column basis. The point is tools use these interfaces and methods heavily to deliver their
functionality.
                  
> Custom CQL protocol/transport
> -----------------------------
>
>                 Key: CASSANDRA-2478
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2478
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Eric Evans
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>              Labels: cql
>         Attachments: cql_binary_protocol
>
>
> A custom wire protocol would give us the flexibility to optimize for our specific use-cases,
and eliminate a troublesome dependency (I'm referring to Thrift, but none of the others would
be significantly better).  Additionally, RPC is bad fit here, and we'd do better to move in
the direction of something that natively supports streaming.
> I don't think this is as daunting as it might seem initially.  Utilizing an existing
server framework like Netty, combined with some copy-and-paste of bits from other FLOSS projects
would probably get us 80% of the way there.

--
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

        

Mime
View raw message