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

Allow custom time_format on cqlsh COPY TO

Agile BoardAttach filesAttach ScreenshotBulk Copy AttachmentsBulk Move AttachmentsVotersWatch issueWatchersCreate sub-taskConvert to sub-taskMoveLinkCloneLabelsUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    Description

      When executing a COPY TO from cqlsh, the user is currently has no control over the format of exported timestamp columns. If the user has indicated a time_format in their cqlshrc file, that format will be used. Otherwise, the system default format will be used.

      The problem comes into play when the timestamp format used on a COPY TO, is not valid when the data is sent back into Cassandra with a COPY FROM.

      For instance, if a user has time_format = %Y-%m-%d %H:%M:%S%Z specified in their cqlshrc, COPY TO will format timestamp columns like this:

      userid|posttime|postcontent
      0|2015-03-14 14:59:00CDT|rtyeryerweh
      0|2015-03-14 14:58:00CDT|sdfsdfsdgfjdsgojr
      0|2015-03-12 14:27:00CDT|sdgfjdsgojr

      Executing a COPY FROM on that same file will produce an "unable to coerce to formatted date(long)" error.

      Right now, the only way to change the way timestamps are formatted is to exit cqlsh, modify the time_format property in cqlshrc, and restart cqlsh. The ability to specify a COPY option of TIME_FORMAT with a Python strftime format, would allow the user to quickly alter the timestamp format for export, without reconfiguring cqlsh.

      aploetz@cqlsh:stackoverflow> COPY posts1 TO '/home/aploetz/posts1.csv' WITH DELIMITER='|' AND HEADER=true AND TIME_FORMAT='%Y-%m-%d %H:%M:%S%z;

      Attachments

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            aploetz Aaron Ploetz Assign to me
            aploetz Aaron Ploetz
            Aaron Ploetz
            Carl Yeksigian
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - 4h
                4h
                Remaining:
                Remaining Estimate - 4h
                4h
                Logged:
                Time Spent - Not Specified
                Not Specified

                Slack

                  Issue deployment