Support Function context aware Repositories operating on a local, filtered data set [DATAGEODE-257]

[spring-projects-issues]

trafficstars

John Blum opened DATAGEODE-257 and commented

It would be ideal if a Function bound, Spring Data Repository took context into consideration when performing Repository data access operations.

For instance, if an application-defined Repository is injected into and used in an Apache Geode Function (perhaps a Function annotated with @GemfireFunction in SDG's Function Annotation support), and if the associated Region of the Repository matches when the Function is "executed" on a Region (with @OnRegion), then the Repository would operate on the "local" (possibly, "filtered") data set provided by the FunctionContext.

One such test example exists here along with it's Function definition and Function execution.

However, there are many things that need to be considered carefully as not to adversely affect any existing functionality or behavior. Using Repositories in Functions is quite common in practice. The following list, though not exhaustive, needs to be taken in consideration:

1. Repositories with an @Region annotation on the Repository itself, or indirectly on the associated application domain object does not match the RegionFunctionContext of the Region targeted Function execution.

2. Functions executed via @OnMember(s) or @OnServer{s) should be excluded.

3. Repositories defining raw OQL using the @Query annotation need to be handled appropriately.

4. Repositories with "custom" implemented methods also need to be handled properly.

5. ???

---

Reference URL: https://jira.spring.io/browse/SGF-451

[spring-projects-issues]

John Blum commented

This feature improvement depends on DATAGEODE-244

[spring-projects-issues]

John Blum commented

Additional considerations that must be carefully handled (otherwise, SDG runs the risk of working in some contexts while breaking in others)

1. First, only the Region.query(:String) API can be used to execute a (OQL) query on the local data set of a PR inside a Function execution. Using the QueryService API, obtained from region.getRegionService().getQueryService() operates on the entire Region.

2. #1 leads to the second limitation, and probably most pertinent... Under-the-hood, SD[G] Repositories use the QueryService API and not Region.query(:String) to execute queries.

Therefore, the underlying infrastructure need to become context sensitive in order to know when to use the Region.query(predicate:String) API call while still preserving the entire Region data access operations in a non-Function context.

3. But, to even be able to operate on the local data set of Region upon which the Function maybe executing, you must first be given subclass of FunctionContext, the RegionFunctionContext. Then, the PartitionRegionHelper.getLocalDataForContext(:RegionFunctionContext) call can be used to get a Region instance that refers to the local data set of the PR. The call returns a Region reference you use to call Region.query(:String) method from within the application-defined Function which is using the Repository.

4. However, using PartitionRegionHelper.getLocalDataForContext(:RegionFunctionContext) puts a further stipulation on your Function execution that it must have been executed with Executions.onRegion(String) (on in SDG, using the @OnRegion(s) annotation on the Function execution interface). As such a onServers or onMembers call will not result in a RegionFunctionContext.

5. ???