[
https://issues.apache.org/jira/browse/PHOENIX-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259210#comment-14259210
]
Lars Hofhansl commented on PHOENIX-1516:
----------------------------------------
Thanks [~giacomotaylor], as usually.
bq. calling the reset after a row has been processed or before the next row is
processed
I think that's the current patch is doing. The call is done in the next method,
but it is not done when we're placed before the first row, so it is offset by
one, and hence the reset logically happens after a row is processed (at least
that is the intent).
In filters it is indeed the case, that we collect the result (as row) and then
call next on the filter, requiring to keep intermediary state as a copy. Meh.
I will look into cloning the RowProjector, better than turning of the
optimization. Will get to this in the next few days. Maybe in time for 4.3.1 or
4.4...?
> Add RANDOM built-in function
> ----------------------------
>
> Key: PHOENIX-1516
> URL: https://issues.apache.org/jira/browse/PHOENIX-1516
> Project: Phoenix
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Attachments: 1516-v2.txt, 1516-v3.txt, 1516.txt
>
>
> I often find it useful to generate some rows with random data.
> Here's a simple RANDOM() function that we could use for that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
