Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-3761 CQL 3.0
  3. CASSANDRA-4217

Easy access to column timestamps (and maybe ttl) during queries

    Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Fix Version/s: 1.1.2
    • Component/s: CQL
    • Labels:

      Description

      It would be interesting to allow accessing the timestamp/ttl of a column though some syntax like

      SELECT key, value, timestamp(value) FROM foo;
      

      and the same for ttl.

      I'll note that currently timestamp and ttl are returned in the resultset because it includes thrift Column object, but adding such syntax would make our future protocol potentially simpler as we wouldn't then have to care about timestamps explicitely (and more compact in general as we would only return timestamps when asked)

      1. 4217.txt
        20 kB
        Sylvain Lebresne

        Activity

        Hide
        jbellis Jonathan Ellis added a comment -

        Good idea. I'd also note as additional motivation that even though we return timestamps now in the Thrift api, there's no way for SQL-oriented drivers to expose it.

        The only wrinkle is that "timestamp" is the name of a SQL datatype... is there an alternative function name we could use? timestampof(value), maybe?

        Show
        jbellis Jonathan Ellis added a comment - Good idea. I'd also note as additional motivation that even though we return timestamps now in the Thrift api, there's no way for SQL-oriented drivers to expose it. The only wrinkle is that "timestamp" is the name of a SQL datatype... is there an alternative function name we could use? timestampof(value), maybe?
        Hide
        slebresne Sylvain Lebresne added a comment -

        We could go for lazy and use ts(value)

        Show
        slebresne Sylvain Lebresne added a comment - We could go for lazy and use ts(value)
        Hide
        ardot Rick Shaw added a comment -

        Could this be the tipping point for a proposal to add functions to the CQL3 grammar and a plugin mechanism to define function methods?

        Show
        ardot Rick Shaw added a comment - Could this be the tipping point for a proposal to add functions to the CQL3 grammar and a plugin mechanism to define function methods?
        Hide
        jbellis Jonathan Ellis added a comment -

        If we do, the now special case for timestamps is first against the wall (to be turned into a real function).

        Show
        jbellis Jonathan Ellis added a comment - If we do, the now special case for timestamps is first against the wall (to be turned into a real function).
        Hide
        jbellis Jonathan Ellis added a comment -

        More seriously, I think "real" function support is a ton of work, and way below other things on my priority list (chiefly, CASSANDRA-1123 and CASSANDRA-3647), and if we can do a quick hack to support timestamps in cql in the meantime, that's probably worth doing.

        Show
        jbellis Jonathan Ellis added a comment - More seriously, I think "real" function support is a ton of work, and way below other things on my priority list (chiefly, CASSANDRA-1123 and CASSANDRA-3647 ), and if we can do a quick hack to support timestamps in cql in the meantime, that's probably worth doing.
        Hide
        thepaul paul cannon added a comment -

        I've dealt with a couple people recently who were quite confused about timestamps- thinking that column values or names which happened to be of cql type "timestamp" were the same thing as column timestamps. It might be helpful if we had some sort of different terminology for these. Something more different than "timestampof" or "ts". "coltimestamp", at least, or maybe something like "writetime"?

        Not to bikeshed unnecessarily, but that extra data point may help.

        Show
        thepaul paul cannon added a comment - I've dealt with a couple people recently who were quite confused about timestamps- thinking that column values or names which happened to be of cql type "timestamp" were the same thing as column timestamps. It might be helpful if we had some sort of different terminology for these. Something more different than "timestampof" or "ts". "coltimestamp", at least, or maybe something like "writetime"? Not to bikeshed unnecessarily, but that extra data point may help.
        Hide
        slebresne Sylvain Lebresne added a comment -

        I'll agree with Jonathan that general functions support is more work than I want to put here. Nor is it my top priority either to be honest (I don't see that as a necessity for a final version of CQL 3.0.0).

        Anyway, attaching patch for this. For the timestamp, I've picked writetime currently, though thinking of it now I realize it is slightly incoherent with the fact that we use 'USING TIMESTAMP' to specify it at insert time, so maybe timestampof is better. Anyway, that will be trivial to change to whatever we settle for.

        Show
        slebresne Sylvain Lebresne added a comment - I'll agree with Jonathan that general functions support is more work than I want to put here. Nor is it my top priority either to be honest (I don't see that as a necessity for a final version of CQL 3.0.0). Anyway, attaching patch for this. For the timestamp, I've picked writetime currently, though thinking of it now I realize it is slightly incoherent with the fact that we use 'USING TIMESTAMP' to specify it at insert time, so maybe timestampof is better. Anyway, that will be trivial to change to whatever we settle for.
        Hide
        jbellis Jonathan Ellis added a comment -

        How about "updatetime" ?

        Show
        jbellis Jonathan Ellis added a comment - How about "updatetime" ?
        Hide
        slebresne Sylvain Lebresne added a comment -

        One slight advantage of writetime over either updatetime or inserttime is that it doesn't suggest that it's the time of update or insert "in the sense of SQL". But that's a minor detail I guess, and again I'm fine going with whatever others prefer, just wanted to mention it.

        Show
        slebresne Sylvain Lebresne added a comment - One slight advantage of writetime over either updatetime or inserttime is that it doesn't suggest that it's the time of update or insert "in the sense of SQL". But that's a minor detail I guess, and again I'm fine going with whatever others prefer, just wanted to mention it.
        Hide
        xedin Pavel Yaskevich added a comment -

        Sylvain, can you please rebase?

        Show
        xedin Pavel Yaskevich added a comment - Sylvain, can you please rebase?
        Hide
        slebresne Sylvain Lebresne added a comment -

        Attaching rebased patch.

        Show
        slebresne Sylvain Lebresne added a comment - Attaching rebased patch.
        Hide
        xedin Pavel Yaskevich added a comment -

        +1

        Show
        xedin Pavel Yaskevich added a comment - +1
        Hide
        slebresne Sylvain Lebresne added a comment -

        Committed, thanks.

        Btw, my patch was using 'writetime'. Is that fine for everyone? It's still time to change.

        Show
        slebresne Sylvain Lebresne added a comment - Committed, thanks. Btw, my patch was using 'writetime'. Is that fine for everyone? It's still time to change.
        Hide
        jbellis Jonathan Ellis added a comment -

        WFM.

        Show
        jbellis Jonathan Ellis added a comment - WFM.

          People

          • Assignee:
            slebresne Sylvain Lebresne
            Reporter:
            slebresne Sylvain Lebresne
            Reviewer:
            Pavel Yaskevich
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development