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

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

          People

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

            Dates

            • Created:
              Updated:

              Development