Uploaded image for project: 'Calcite'
  1. Calcite
  2. CALCITE-797

Avatica remote service strips the date part from java.sql.Time

    Details

    • Type: Bug
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      java.sql.Time is basically an UNIX timestamp with both date and time. The documentation says the date part should not be used, but Phoenix does use it. While it is possible to pass the full timestamp as a parameter value, the client will only get time part back.

      Given that using the date part is deprecated according to the documentation, I'm not sure if you want to support this.

        Activity

        Hide
        julianhyde Julian Hyde added a comment -

        I think Avatica is doing the right thing in stripping the date part and leaving the milliseconds since midnight. java.sql.Time is merely a binding of SQL types into the Java language, but when you go across a network protocol and into a database we don't guarantee Java semantics end-to-end.

        Show
        julianhyde Julian Hyde added a comment - I think Avatica is doing the right thing in stripping the date part and leaving the milliseconds since midnight. java.sql.Time is merely a binding of SQL types into the Java language, but when you go across a network protocol and into a database we don't guarantee Java semantics end-to-end.
        Hide
        lukaslalinsky Lukas Lalinsky added a comment -

        Do you have a suggestion about the Phoenix query server? Should it somehow override this behavior, in order to allow access to all the data that the native JDBC interface has access to?

        Show
        lukaslalinsky Lukas Lalinsky added a comment - Do you have a suggestion about the Phoenix query server? Should it somehow override this behavior, in order to allow access to all the data that the native JDBC interface has access to?
        Hide
        lukaslalinsky Lukas Lalinsky added a comment -

        One more thing to consider. The values are currently flagged with the internal-representation type, not the SQL type. For example, clients are sending sending

        {"type":"JAVA_SQL_TIME":"value":123}

        not

        {"type":"TIME":"value":123}

        Given this, it make sense to send the full java.sql.Time representation. If you want to keep standard SQL behavior, then perhaps it would make sense to rename the types.

        Show
        lukaslalinsky Lukas Lalinsky added a comment - One more thing to consider. The values are currently flagged with the internal-representation type, not the SQL type. For example, clients are sending sending {"type":"JAVA_SQL_TIME":"value":123} not {"type":"TIME":"value":123} Given this, it make sense to send the full java.sql.Time representation. If you want to keep standard SQL behavior, then perhaps it would make sense to rename the types.
        Hide
        julianhyde Julian Hyde added a comment -

        I have re-opened the issue since there seems more to discuss.

        Lukas Lalinsky, I agree it makes sense to send the full java.sql.Time value (i.e. in prepare). But I think the values returned (i.e. in fetch) should be SQL TIME values, with no date part.

        Although this is asymmetric, it is consistent with the JDBC API: the types of parameters are determined by the client (whatever type of Java object the client chooses to supply) whereas the types of columns in a result set are determined by the server.

        Show
        julianhyde Julian Hyde added a comment - I have re-opened the issue since there seems more to discuss. Lukas Lalinsky , I agree it makes sense to send the full java.sql.Time value (i.e. in prepare). But I think the values returned (i.e. in fetch) should be SQL TIME values, with no date part. Although this is asymmetric, it is consistent with the JDBC API: the types of parameters are determined by the client (whatever type of Java object the client chooses to supply) whereas the types of columns in a result set are determined by the server.

          People

          • Assignee:
            julianhyde Julian Hyde
            Reporter:
            lukaslalinsky Lukas Lalinsky
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development