[
https://issues.apache.org/jira/browse/BEAM-6067?focusedWorklogId=171497&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-171497
]
ASF GitHub Bot logged work on BEAM-6067:
----------------------------------------
Author: ASF GitHub Bot
Created on: 03/Dec/18 09:17
Start Date: 03/Dec/18 09:17
Worklog Time Spent: 10m
Work Description: robertwb commented on a change in pull request #7081:
[BEAM-6067] In Python SDK, specify pipeline_proto_coder_id property in
non-Beam-standard CloudObject coders
URL: https://github.com/apache/beam/pull/7081#discussion_r238189720
##########
File path: sdks/python/apache_beam/runners/dataflow/dataflow_runner.py
##########
@@ -441,22 +443,25 @@ def _get_side_input_encoding(self, input_encoding):
def _get_encoded_output_coder(self, transform_node, window_value=True):
"""Returns the cloud encoding of the coder for the output of a
transform."""
+ from apache_beam.runners.dataflow.internal import apiclient
if (len(transform_node.outputs) == 1
and transform_node.outputs[None].element_type is not None):
# TODO(robertwb): Handle type hints for multi-output transforms.
element_type = transform_node.outputs[None].element_type
+ use_fnapi =
apiclient._use_fnapi(transform_node.outputs[None].pipeline._options)
else:
# TODO(silviuc): Remove this branch (and assert) when typehints are
# propagated everywhere. Returning an 'Any' as type hint will trigger
# usage of the fallback coder (i.e., cPickler).
element_type = typehints.Any
+ use_fnapi = False # TODO(chambers): XXX do the right thing for this
Review comment:
I read this as "if there are multiple outputs, don't use the fn api" but I
understand your intent now.
Just thinking about this again, another option would be to simply choose any
output on which to check for the fn api flag. This shouldn't(?) be called if
there are no outputs.
As for the test failure, it feels like we're working around a still-present
bug. But as you say, it may just be brittle testing.
As for how this code becomes obsolete, the Dataflow service should just
accept FnApi protos directly, rather than have each SDK translate it to cloud
objects just to try to get them translated to the right DFE objects on the
other end.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 171497)
Time Spent: 6h 10m (was: 6h)
Remaining Estimate: 161h 50m (was: 162h)
> Dataflow runner should include portable pipeline coder id in CloudObject
> coder representation
> ---------------------------------------------------------------------------------------------
>
> Key: BEAM-6067
> URL: https://issues.apache.org/jira/browse/BEAM-6067
> Project: Beam
> Issue Type: Improvement
> Components: beam-model
> Reporter: Craig Chambers
> Assignee: Craig Chambers
> Priority: Major
> Original Estimate: 168h
> Time Spent: 6h 10m
> Remaining Estimate: 161h 50m
>
> When translating a BeamJava Coder into the DataflowRunner's CloudObject
> property map, include a property that specifies the id in the Beam model
> Pipeline coders map corresponding to that Coder. This will allow the
> DataflowRunner to reference the corresponding Beam coder in the FnAPI
> processing bundle.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
