Hey all
In an effort to clean up hanging issues, we just pushed a new 2.2 wip with some minor changes to TupleEntry
http://docs.concurrentinc.com/cascading/2.2/javadoc/cascading/tuple/TupleEntry.html
Specifically around #selectTuple and #selectEntry
http://docs.concurrentinc.com/cascading/2.2/javadoc/cascading/tuple/TupleEntry.html#selectTuple(cascading.tuple.Fields)
http://docs.concurrentinc.com/cascading/2.2/javadoc/cascading/tuple/TupleEntry.html#selectEntry(cascading.tuple.Fields)
In prior releases, the behavior was non obvious without looking at the code, so we have tightened the contract and updated the javadoc.
The net of it is, #selectTuple/Entry will return objects that now retain the mutability of the current TupleEntry.
The best example of use can be seen in the UnGroup Function
https://github.com/cwensel/cascading/blob/wip-2.2/cascading-core/src/main/java/cascading/operation/function/UnGroup.java#L176
for( Fields resultFieldSelector : resultFieldSelectors )
{
Tuple group = input.selectTupleCopy( groupFieldSelector ); // need a mutable copy
group.addAll( input.selectTuple( resultFieldSelector ) ); // no copy needed
outputCollector.add( group );
}
#selectTupleCopy guarantees we get a new Tuple we can modify. but #selectTuple can make decisions that provide the best performance, hopefully not making a new Tuple instance if its needless.
The semantics have always been there, but they were too lose and problematic.
Moving forward if you see exceptions stating your tuple can't be modified, use the #select*Copy() versions.
fwiw, looking at that above code, we clearly need a #selectInto() method to prevent the intermediate Tuple instance as well, grin
ckw
--
Chris K Wensel
ch...@concurrentinc.com
http://concurrentinc.com