[
https://issues.apache.org/jira/browse/PHOENIX-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17320554#comment-17320554
]
Kadir Ozdemir commented on PHOENIX-6434:
----------------------------------------
[~larsh], the bug you have found with phoenix_row_timestamp() happens when the
where clause includes phoenix_row_timestamp() and the projection includes just
the wildcard *. The root cause of the bug is that PhoenixRowTimestampParseNode
adds the empty column to the scan (using Scan#addColumn()). However, when the
projection of a select statement includes the wildcard, Phoenix does not add
any columns to scans, which results in getting all columns back from HBase.
However, when PhoenixRowTimestampParseNode adds the empty column the scan, the
scan returns only the empty column in this case, and this why your test got
null value for the other columns. I will fix this in the next version of the
PR. Thanks for finding this issue.
> Secondary Indexes on PHOENIX_ROW_TIMESTAMP()
> --------------------------------------------
>
> Key: PHOENIX-6434
> URL: https://issues.apache.org/jira/browse/PHOENIX-6434
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 5.1.0, 4.16.0
> Reporter: Kadir Ozdemir
> Priority: Major
> Attachments: PHOENIX-6434.4.x.001.patch, PHOENIX-6434.4.x.002.patch,
> PHOENIX-6434.4.x.003.patch
>
>
> PHOENIX-5629 introduced the function PHOENIX_ROW_TIMESTAMP() that returns the
> last modified time of a row. PHOENIX_ROW_TIMESTAMP() can be used as a
> projection column and referred in a WHERE clause. It is desirable to have
> indexes on row timestamps. This will result in fast time range queries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
