Dan Smith created GEODE-726:
-------------------------------
Summary: Add a getLocalDataSet to RegionFunctionContext and
deprecate PartitionRegionHelper.getLocalData(RegionFunctionContext)
Key: GEODE-726
URL: https://issues.apache.org/jira/browse/GEODE-726
Project: Geode
Issue Type: Bug
Reporter: Dan Smith
>From
>https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments#FunctionServiceUsabilityImprovments-RegionFunctionContextshouldprovidethelocaldataset
> :
If you want to operate on the local data set for a function, you have to do this
{code}
public void execute(FunctionContext context) {
RegionFunctionContext ctx = (RegionFunctionContext) context;
//This actually doesn't give you the local data set
Region wholePartitionedRegion = ctx.getDataSet();
//This does, using a static function call
Region localData = PartitionRegionHelper.getLocalDataForContext(ctx);
//This is a bad idea, because it may include some buckets that are also
being processed on other nodes
Region localDataDontDoThis =
PartitionRegionHelper.getLocalData(ctx.getDataSet());
{code}
There are several problems with this approach.
* It's not clear that ctx.getDataSet does not return the local data.
* The local data set is not mockable for unit tests, because this static
function call extracts it using internal APIs on concrete classes. This
prevents this sort of function from being tested in a pure unit test.
* The user has to know that PartitionRegionHelper exists; the API is not
obvious
* The various methods on PartitionRegionHelper are confusing, specifically
it's unclear to a user why they should use getLocalDataForContext instead of
getLocalData
RegionFunctionContext should just provide a getLocalDataSet method. We should
add this new method to the RegionFunctionContext interface. We should deprecate
the PartitionRegionHelper.getLocalDataForContext.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
