[
https://issues.apache.org/jira/browse/PHOENIX-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368373#comment-14368373
]
ASF GitHub Bot commented on PHOENIX-1744:
-----------------------------------------
Github user dhacker1341 commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/48#discussion_r26725524
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/schema/types/PUnsignedLong.java
---
@@ -95,6 +95,11 @@ public Object toObject(byte[] b, int o, int l, PDataType
actualType, SortOrder s
}
@Override
+ public boolean isCastableTo(PDataType targetType) {
--- End diff --
The problem with that is the smaller. Numbers in the jira like 22847 wind
up being integer and not long so without doing both you have an arbitrarily
small number where things just start working so cast(12949 as timestamp) will
not work but cast(284484849 as timestamp) will.
> On Mar 18, 2015, at 7:00 PM, James Taylor <notificati...@github.com>
wrote:
>
> In
phoenix-core/src/main/java/org/apache/phoenix/schema/types/PUnsignedLong.java:
>
> > @@ -95,6 +95,11 @@ public Object toObject(byte[] b, int o, int l,
PDataType actualType, SortOrder s
> > }
> >
> > @Override
> > + public boolean isCastableTo(PDataType targetType) {
> Was thinking to only make this change so that an UNSIGNED_LONG is
castable to a TIMESTAMP. Allowing an INTEGER to be cast to a TIMESTAMP seems
weird to me. How about we just start with this change for now and you adjust
your tests accordingly?
>
> —
> Reply to this email directly or view it on GitHub.
>
> CAST from UNSIGNED_LONG (_INT) to * TIMESTAMP is not supported.
> ---------------------------------------------------------------
>
> Key: PHOENIX-1744
> URL: https://issues.apache.org/jira/browse/PHOENIX-1744
> Project: Phoenix
> Issue Type: Bug
> Reporter: Serhiy Bilousov
> Assignee: Dave Hacker
> Priority: Minor
>
> Epoch time can be represented as INTEGER (up to the seconds) or LONG (up to
> the millisecond). Currently CAST from UNSIGNED_LONG to TIMESTAMP not
> supported by Phoenix.
> It make sense to have support for conversion from epoch (4 bytes or 8 bytes)
> to any datetime like format curently supported by Phoenix (TIME, DATE,
> TIMESTAMP, UNSIGNED_TIME, UNSIGNED_DATE, UNSIGNED_TIMESTAMP).
> HBase shell:
> {noformat}
> create 't','f1'
> put
> 't',"\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x01L\x0Fz,\x1E",'f1:c1','test'
> {noformat}
> sqlline:
> {noformat}
> CREATE VIEW vT
> ( a UNSIGNED_INT NOT NULL
> ,b UNSIGNED_INT NOT NULL
> ,ts UNSIGNED_LONG NOT NULL
> CONSTRAINT pk PRIMARY KEY (a, b, ts))
> AS SELECT * FROM "t"
> DEFAULT_COLUMN_FAMILY ='f1';
> select a, b, ts, CAST(1426188807198 AS TIMESTAMP) from vt;
> +----+----+----------------+------------------------------+
> | A | B | TS | TO_TIMESTAMP(1426188807198) |
> +----+----+----------------+------------------------------+
> | 1 | 1 | 1426188807198 | 2015-03-12 19:33:27.198 |
> +----+----+----------------+------------------------------+
> {noformat}
> but
> {noformat}
> select a, b, ts, CAST(ts AS TIMESTAMP) from vt;
> Error: ERROR 203 (22005): Type mismatch. UNSIGNED_LONG and TIMESTAMP for TS
> (state=22005,code=203)
> {noformat}
> As per Gabriel Reid
> {quote}
> As a workaround, you can cast the UNSIGNED_LONG to a BIGINT first, and then
> cast it to a TIMESTAMP, i.e.
> select a, b, ts, CAST(CAST(ts AS BIGINT) AS TIMESTAMP) from vt;
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
