[
https://issues.apache.org/jira/browse/STORM-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14503036#comment-14503036
]
ASF GitHub Bot commented on STORM-789:
--------------------------------------
Github user dan-blanchard commented on a diff in the pull request:
https://github.com/apache/storm/pull/525#discussion_r28699109
--- Diff: storm-core/src/jvm/backtype/storm/task/TopologyContext.java ---
@@ -205,32 +217,65 @@ public Object getTaskData(String name) {
public void setExecutorData(String name, Object data) {
_executorData.put(name, data);
}
-
+
public Object getExecutorData(String name) {
return _executorData.get(name);
- }
-
+ }
+
public void addTaskHook(ITaskHook hook) {
hook.prepare(_stormConf, this);
_hooks.add(hook);
}
-
+
public Collection<ITaskHook> getHooks() {
return _hooks;
}
+
+ public Object groupingToJSONableObject(Grouping grouping) {
+ if (grouping.is_set_fields()) {
+ return grouping.get_fields();
+ } else {
+ return grouping.getSetField().toString();
+ }
--- End diff --
I understand wanting to make something that's easily extensible in the
future, but the example you showed wouldn't ever happen, because only the
fields grouping specifies fields. If you think it should return a dictionary
that always contains `type` and `fields`, we'd get the following for shuffle
groupings:
```json
{
"type": "SHUFFLE",
"fields": null
}
```
and
```json
{
"type": "FIELDS",
"fields": ["a", "b"]
}
```
for fields groupings.
> Enhance topology context sent to multi-lang bolts and spouts
> ------------------------------------------------------------
>
> Key: STORM-789
> URL: https://issues.apache.org/jira/browse/STORM-789
> Project: Apache Storm
> Issue Type: Improvement
> Reporter: Dan Blanchard
> Assignee: Dan Blanchard
>
> I'm about to submit a pull request that adds a lot more contextual
> information to the "context" JSON dictionary that gets sent to multi-lang
> bolts and spouts as part of their initial handshake. These additions will
> make is so non-JVM developers have access to the sources, targets, and field
> names for their bolts and spouts.
> We will add support for this in streamparse (one of the more popular Python
> libraries for Storm) as soon as this gets merged in.
> Here are the details of what I've added:
> - componentid: the component ID for this task, so you don't have to look it
> up
> in "task->component" by "taskid"
> - streams: a list of all of the streams for this task
> - stream->outputfields: a mapping from stream names to output fields for
> that
> stream
> - stream->target->grouping: a mapping from stream names to the targets for
> this
> task to the kind of grouping they use.
> - sources->grouping: a mapping from the component IDs of the sources to
> their
> grouping.
> Note on groupings: groupings are either represented as a string (e.g.,
> "SHUFFLE") or a list of strings for field groupings.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
