Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-11099

Prepared metadata does not include CAS applied column

      Details

      • Type: Improvement
      • Status: Open
      • Priority: Minor
      • Resolution: Unresolved
      • Fix Version/s: None
      • Component/s: None
      • Labels:

        Description

        When executing a CAS statement the first column is the [applied] boolean column indicating success, but when preparing it does get returned. This means that clients can not cache the prepared statement result metadata to use instead of the execute metadata.

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          slebresne Sylvain Lebresne added a comment -

          The problem is that the result set of a CAS statement is not stable across execution: if the write succeed then it will only contain the [applied] column, but if it doesn't apply, it will also return the columns on which their was conditions. In other words, we can't do that currently.

          Now, I suppose we could change how we do that and always return the same resultSet, with both [applied] and the columns having conditions, but return null for those columns if [applied] == true, but that's strictly speaking a breaking change and so at best we should do that in the next version of the protocol. So marking the ticket accordingly.

          Show
          slebresne Sylvain Lebresne added a comment - The problem is that the result set of a CAS statement is not stable across execution: if the write succeed then it will only contain the [applied] column, but if it doesn't apply, it will also return the columns on which their was conditions. In other words, we can't do that currently. Now, I suppose we could change how we do that and always return the same resultSet, with both [applied] and the columns having conditions, but return null for those columns if [applied] == true , but that's strictly speaking a breaking change and so at best we should do that in the next version of the protocol. So marking the ticket accordingly.
          Hide
          Permalink
          Zariel Chris Bannister added a comment -

          I realised when I started looking into the returned metadata that is not as simple as I had thought. I would be great to have fixed for protocol 5 though. Another option to mitigate is that if a client requests skip_metadata for a CAS statement Cassandra should ignore it and return the result metadata, this shouldn't be breaking.

          Show
          Zariel Chris Bannister added a comment - I realised when I started looking into the returned metadata that is not as simple as I had thought. I would be great to have fixed for protocol 5 though. Another option to mitigate is that if a client requests skip_metadata for a CAS statement Cassandra should ignore it and return the result metadata, this shouldn't be breaking.

            People

            • Assignee:
              Unassigned
              Reporter:
              Zariel Chris Bannister
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:

                Development