[
https://issues.apache.org/jira/browse/CASSANDRA-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13283379#comment-13283379
]
Sylvain Lebresne commented on CASSANDRA-2478:
---------------------------------------------
bq. The ResultSetMetaData interface provides methods for getSchemaName(column)
and getTableName(column) on a column-by-column basis
Which begs the question: do we want to also allow per-column keyspace/table
names? As of C* current state this is not needed, one can only query one at a
time. But wiring that in the protocol could be limiting in the future. On the
other side, it will more simple/compact to only allow 1 keyspace/table name and
adding query on multiple table, if we ever do it, won't be a small addition, so
maybe we're fine with having it trigger a bump in the protocol version when
that happen.
I suppose we could support both version through a simple flag that say whether
there is just one keyspace/table pair or one per column, but that complicates
the protocol for something that may well never be useful. Opinions?
bq. use this as an opportunity to get rid of our custom
authentication/authorization, and add hooks for SASL instead
I'm not against that in theory. But I'll admit not knowing all the nuts and
bolts of SASL. From an initial read, it seems the protocol part is fairly
simple, it's a just a couple of simple message carrying string to support.
However what's less clear to me is how to wire that in the Cassandra side and
in particular how to ensure some form of compatibility with our current
IAuthenticator interface.
> 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
