Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Fix Version/s: 0.8 beta 1
    • Component/s: CQL
    • Labels:

      Description

      CQL (Cassandra Query Language) is a proposed language for data management in Cassandra.

      This issue is meant to encapsulate the goals for CQL in the next stable release (0.8), roughly:

      • Completed 1.0 language specification.
      • Implementation of the language using the Avro interface for transport and serialization.
      • Low-level drivers for Java and Python (possibly others).
      • The deprecation (or removal, TBD) of (Avro) RPC methods.

      Separate tickets with the appropriate relationships to this one will be created for the individual tasks.

      Edit (2011-01-21): Changed short description from "CQL 1.0" to "CQL 0.99".
      Edit (2011-04-14): Changed it back. Whatever.

      CQL 1.0 needn't be entirely complete, but it should be stable. Backward incompatible changes mean a transition to 2.0 (and I hope there is never a 2.0). However, I don't think it will have baked long enough to be called "1.0" in the next release (0.7+1), so let's call that 0.99 (to signal the possibility of backward incompatible changes), and target 0.7+2 for CQL 1.0.

        Activity

        Hide
        urandom Eric Evans added a comment -

        The release goals for CQL 1.0 are complete; Closing this issue.

        Show
        urandom Eric Evans added a comment - The release goals for CQL 1.0 are complete; Closing this issue.
        Hide
        urandom Eric Evans added a comment -

        I generally like this proposal, except I don't think we should get rid of the rpc methods.

        Just to be clear, the RPC methods I'm referring to here are the Avro RPC methods (not Thrift).

        Sometimes the performance will be worth it (assuming that the direct rpc will be faster, which seems to be a safe assumption).

        The back-of-napkin tests I've done so far put CQL and Thrift on even footing, and there is a ton of room for improvement on the CQL-side (ditching the HTTP transport for example). Proper benchmarks need to be done to be sure, but I'm operating on the assumption that greater-than or equal-to performance is possible.

        Show
        urandom Eric Evans added a comment - I generally like this proposal, except I don't think we should get rid of the rpc methods. Just to be clear, the RPC methods I'm referring to here are the Avro RPC methods (not Thrift). Sometimes the performance will be worth it (assuming that the direct rpc will be faster, which seems to be a safe assumption). The back-of-napkin tests I've done so far put CQL and Thrift on even footing, and there is a ton of room for improvement on the CQL-side (ditching the HTTP transport for example). Proper benchmarks need to be done to be sure, but I'm operating on the assumption that greater-than or equal-to performance is possible.
        Hide
        kingryan Ryan King added a comment -

        I generally like this proposal, except I don't think we should get rid of the rpc methods. Sometimes the performance will be worth it (assuming that the direct rpc will be faster, which seems to be a safe assumption).

        Show
        kingryan Ryan King added a comment - I generally like this proposal, except I don't think we should get rid of the rpc methods. Sometimes the performance will be worth it (assuming that the direct rpc will be faster, which seems to be a safe assumption).

          People

          • Assignee:
            urandom Eric Evans
            Reporter:
            urandom Eric Evans
          • Votes:
            3 Vote for this issue
            Watchers:
            14 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development