Just a friendly reminder that PR 2094 resolved some of the issue mentioned
here, but a bit remains in terms of fully consolidating the semantics.
Merging the PR as soon as Travis comes in green.
The reminder is documented in [1].
[1] https://issues.apache.org/jira/browse/FLINK-5156
On Thu, Nov 3
Thanks for bringing up the issue, Fabian.
I am also for unifying the access patterns between the FieldAccessor and
ExpressionKeys logic.
In terms of Fabian's suggestion to refactor the ExpressionKeys parsing
logic and rely on it in the FieldAccessors I think that is nice first step.
It would be g
IMO, FieldAccessors are certainly valuable and should exist.
I only want to make sure that there is a common syntax for field references.
Maybe we can refactor the parsing code for field references in
ExpressionKeys and expose it in static public methods that the
FieldAccessors can call.
Best,
Fa
Hello,
Thanks Fabian for starting this discussion.
I would just like to add a few thougths about why does the
FieldAccessors even exist. One could say that we should instead just
re-use ExpressionKeys for the aggregations, and we are done. As far as
I can see, the way ExpressionKeys is often used
Hi everybody,
while reviewing PR #2094 [1] I noticed that the field reference syntax for
FieldAccessors is not compatible with the syntax supported for key
definitions (ExpressionKeys) used in groupBy(), keyBy(),
join().where().equalTo(), etc.
FieldAccessors are only used for build-in aggregation
