[
https://issues.apache.org/jira/browse/FLINK-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Greg Hogan updated FLINK-2668:
------------------------------
Description:
I have come across an issue in my code where I called project(...) on a
{{DataSet}} which was already a {{ProjectOperator}}. Instead of reducing the
number of fields from 2 to 1 this instead increased the number of fields from 2
to 3 resulting in
{{org.apache.flink.api.common.functions.InvalidTypesException: Input mismatch:
Tuple arity '3' expected but was '1'.}} when processing the next operator.
This can be resolved by adding an optional explicit call to conclude the
projection, perhaps {{ProjectOperator.closeProjection()}}. Can this be done
without creating a new no-op operator?
was:
I have come across an issue in my code where I called project(...) on a DataSet
which was already a ProjectOperator. Instead of reducing the number of fields
from 2 to 1 this instead increased the number of fields from 2 to 3 resulting
in org.apache.flink.api.common.functions.InvalidTypesException: Input mismatch:
Tuple arity '3' expected but was '1'. when processing the next operator.
This can be resolved by adding an optional explicit call to conclude the
projection, perhaps ProjectOperator.closeProjection(). Can this be done without
creating a new no-op operator?
> ProjectOperator method to close projection
> ------------------------------------------
>
> Key: FLINK-2668
> URL: https://issues.apache.org/jira/browse/FLINK-2668
> Project: Flink
> Issue Type: Improvement
> Components: Java API
> Affects Versions: master
> Reporter: Greg Hogan
> Priority: Minor
>
> I have come across an issue in my code where I called project(...) on a
> {{DataSet}} which was already a {{ProjectOperator}}. Instead of reducing the
> number of fields from 2 to 1 this instead increased the number of fields from
> 2 to 3 resulting in
> {{org.apache.flink.api.common.functions.InvalidTypesException: Input
> mismatch: Tuple arity '3' expected but was '1'.}} when processing the next
> operator.
> This can be resolved by adding an optional explicit call to conclude the
> projection, perhaps {{ProjectOperator.closeProjection()}}. Can this be done
> without creating a new no-op operator?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
