These commits address #25 and add some improved semantics to the Clojure DSL.
Stream/component/task info on a tuple is now accessible from the meta data.
Tuples now implement ILookup, IPersistentMap, Indexed, Seqable, IFn, and Map so that things like (nth tuple 1), (tuple :foo-field), (:foo-field tuple), etc. work.
Added an IndifferentAccessMap to allow tuple field names to be treated as either keywords or strings.
Tuples can now be "modified" like clojure maps with assoc/dissoc. This is useful for building up values to emit. This is kind of a naive implementation, but I think it works pretty well for the task at hand.
From the Clojure side, emit-bolt!/emit-bolt-direct! can now take its values as either a list or a map. If it is provided a map, then it will find the output fields for the stream and construct the values list from the map based on that (currently null for any fields not present in the map, which I think is sensible). We've been using a pattern like this on our project at NabeWise and I find it to be very powerful/convenient.
I apologize in advance that my java-fu is somewhat weak, so let me know if I need to fix any style or other issues.
Made Tuples operate better in Clojure
* Now implements ILookup, AFn, Seqable, Indexed, IMeta
* Fake tuple generator for testing
Tuple can now be modified as a PersistentMap
Tuple is now also a Map
Working emit with map from clojure
* Should probably refactor a bit and test more
Fixed bugs, added tuple tests
ok, I need to fix some lazy seq bugs. Working on running my project on this version.
Correctly handle arbitrary maps passed to emit
Add test case for emit passed an arbitrary map with mixed symbols and…
I'm not totally sold yet on exposing the TopologyContext in the output collector. I'll have to think if there's a better way to get at that information.
I think that mk-tuple-values should be changed to a protocol. That should be faster and more flexible.
Yeah, that was a dirty hack. I think the better approach would be to let output collectors take a list or a map, but that would require fairly far reaching changes across the system.
I also really need to switch out stringify keys in mk-tuple-values with a comprehension that doesn't mess with values that are maps.
don't use recursive walk to stringify-keys
Change mk-tuple-values into a protocol
Instead of exposing the TopologyContext in OutputCollector, how about we make the Clojure DSL "collector" be a map containing :output-collector and :context. Then the emit and ack functions can be modified appropriately to make use of that and we don't have to change the Java interfaces.
BTW, when you update a pull request leave a comment. Just adding commits doesn't send me a notification :(
Changed clojure bolts and spouts to take a map for collector
Fix type hinting for hinted-args and closures vs. prepare method
Remove access to a collector's context
Okay, I made those changes. Everything seems to work well (at least in storm's test and my project).
silly mistake in args hinting
Merge branch 'master' into clojure_tuples
Merged to latest master