Hey John, Thanks for the reply and sorry for the delay in response. PartitionedRegionHelper.getLocalDataSetForContext thsi method doesnt seem to be available in the geode jars , is there an alternative which does the same??
Regards On Mon, Jan 16, 2017 at 5:34 AM, John Blum <[email protected]> wrote: > Hi Amit- > > Great question! > > By this, I think you mean, you have injected a SD[G] *Repository* in a > (GemFire/Geode) Function executing on a Partitioned Region, and you want to > use the SD[G] Repo to perform a query on the [filtered], "local data set" > (only) of the PR on the cluster node where the Function is executing, > correct? > > Unfortunately, and currently, SD[G] Repos do not distinguish based on > context, e.g. whether the Repo is being used inside a Function, and > particularly where the Function is executing on the local data set of a PR > (possibly filtered even). I.e. SDG *Repository* queries execute on the > whole Region regardless of context and regardless of Region data policy > since a Repo is typed to an application domain object, which is associated > with a Region (via. @Region annotation or by simple class name of the > domain object). > > Even when using the GemFire API, you must call PartitionedRegionHelper. > getLocalDataForContext(:RegionFunctionContext) inside your Function to > access the local data set of the PR on which to perform the query, using > specifically Region.query(predicate:String). SDG Repos exclusively use > the QueryService API. > > Anyway, this is a very loaded problem with many different implications, 1 > for which I have invested a lot of thought, starting with... > > 1. Awhile back, I filed a JIRA (SGF-451 > <https://jira.spring.io/browse/SGF-451> - *Support Function context aware > Repositories operating on the local, filtered data set. > <https://jira.spring.io/browse/SGF-451>* [1]) to address this very thing. > > 2. Additionally, I built a proof-of-concept to test out my ideas, > beginning with this test class > <https://github.com/jxblum/spring-gemfire-tests/blob/master/src/test/java/org/spring/data/gemfire/cache/PeerCacheFunctionExecutionUsingRepositoryOnFilteredLocalDataSetTest.java> > [2], this Repo > <https://github.com/jxblum/spring-gemfire-tests/blob/master/src/main/java/org/spring/data/gemfire/app/dao/repo/ProgrammerRepository.java> > [3] > and this Function > <https://github.com/jxblum/spring-gemfire-tests/blob/master/src/main/java/org/spring/data/gemfire/cache/execute/ProgrammerFunctions.java> > [4]. > > In the interim, you could do the following inside your Function (depending > on how you defined/implemented your Function, i.e. by using SDG's > Function annotation support > <http://docs.spring.io/spring-data-gemfire/docs/current/reference/html/#function-annotations> > [5], > or using GemFire's API directly)... > > ... > > GemfireTemplate regionTemplate = > new GemfireTemplate(PartitionedRegionHelper.getLocalDataSetForContext( > regionFunctionContext)); > > SelectResults selectResults = regionTemplate.query("<predicate here>"); > > // process SelectResults > > > Of course, this is not quite as convenient as using the SD *Repository* > abstraction, but it still gives you a consistent Data Access Exception > Hierarchy and proper participation in *Spring's* Transaction Management, > if using and executing in a transaction. > > There are other ways as well, especially if you are committed to using the > SD *Repository* abstraction. You could, for instance, provide a custom > *Repository* implementation that takes the [Region]FunctionContext (for > example > <https://github.com/jxblum/spring-gemfire-tests/blob/master/src/main/java/org/spring/data/gemfire/app/dao/repo/support/ProgrammerRepositoryImpl.java> > [6]) > and performs the query accordingly (such as by wrapping the snippet of code > I demonstrated above). > > This is a bit more work but still wraps the necessary functionality to > perform the desired query behind a convenient and reusable Repo method call. > > You can usually do anything you want, but some approaches may require > extra thought and be a bit more work (for the time being). > > Sorry for the inconvenience (still working out all the details). > > Hope this helps. > > Cheers, > John > > > [1] https://jira.spring.io/browse/SGF-451 > [2] https://github.com/jxblum/spring-gemfire-tests/blob/ > master/src/test/java/org/spring/data/gemfire/cache/ > PeerCacheFunctionExecutionUsingRepositoryOnFilteredLocalDataSetTest.java > [3] https://github.com/jxblum/spring-gemfire-tests/blob/ > master/src/main/java/org/spring/data/gemfire/app/dao/ > repo/ProgrammerRepository.java > [4] https://github.com/jxblum/spring-gemfire-tests/blob/ > master/src/main/java/org/spring/data/gemfire/cache/ > execute/ProgrammerFunctions.java > [5] http://docs.spring.io/spring-data-gemfire/docs/ > current/reference/html/#function-annotations > [6] https://github.com/jxblum/spring-gemfire-tests/blob/ > master/src/main/java/org/spring/data/gemfire/app/dao/repo/support/ > ProgrammerRepositoryImpl.java > > > On Sun, Jan 15, 2017 at 7:40 AM, Amit Pandey <[email protected]> > wrote: > >> Just to add my cache is ofcourse partitioned, in replicated I understand >> I can query the cache without that problem. >> >> Regards >> >> On Sun, Jan 15, 2017 at 9:09 PM, Amit Pandey <[email protected]> >> wrote: >> >>> I >>> Hi John, >>> >>> I got this working thanks. >>> >>> Using Spring Data does help in making the API cleaner. >>> >>> However I want to ensure in functions that only local data for the >>> partitioned cache is extracted, is there any way to ensure that via Spring >>> Data? >>> >>> This can help to get data if I have PK:- PartitionRegionHelper.getLoca >>> lDataForContext(context) >>> .get(k); >>> >>> But I have to query so is there any way to do it? >>> >>> Regards >>> >>> On Sat, Jan 14, 2017 at 1:25 AM, Amit Pandey <[email protected]> >>> wrote: >>> >>>> Udo and John, >>>> >>>> Many thanks..I could use QueryService. >>>> >>>> However I am getting some weirde errors when I am trying to use >>>> QueryService from inside Geode. I will post here, again tomorrow >>>> >>>> On Sat, Jan 14, 2017 at 1:23 AM, John Blum <[email protected]> wrote: >>>> >>>>> Amit- >>>>> >>>>> You have 3 main and separate ways you query Region data... >>>>> >>>>> 1. Using SD Repositories and SDG's support for them ( >>>>> http://docs.spring.io/spring-data-gemfire/docs/current/refe >>>>> rence/html/#gemfire-repositories.executing-queries) as Udo pointed >>>>> out. >>>>> >>>>> 2. You can use the SDG GemfireTemplate (http://docs.spring.io >>>>> /spring-data-gemfire/docs/current/api/org/springframework/data/gemfire >>>>> /GemfireTemplate.html) >>>>> >>>>> 3. Or, you can simply use the Geode API (i.e. QueryService ( >>>>> http://geode.apache.org/releases/latest/javadoc/org/apache >>>>> /geode/cache/query/QueryService.html), Query, SelectResults, and so >>>>> on). >>>>> >>>>> The interesting tidbit here is that the Repository abstraction and >>>>> SDG's Repository extension for Geode is built on the GemfireTemplate >>>>> (under-the-hood) and GemfireTemplate uses the QueryService API >>>>> (under-the-hood). >>>>> >>>>> However, the advantages of using Spring of Geode's API are... >>>>> >>>>> 1. You get a "consistent" Data Access Exception Hierarchy ( >>>>> http://docs.spring.io/spring/docs/current/spring-framework-reference/ >>>>> htmlsingle/#dao-exceptions) across your entire application regardless >>>>> of data store, particularly useful if you are using more than 1 data >>>>> store, >>>>> but even advisable if you are not, particularly for *Spring*-based >>>>> applications. >>>>> >>>>> 2. Your application code/logic (whether using the *Repository* >>>>> abstraction or your own custom DAOs (using the GemfireTemplate)), >>>>> will automatically pick up and participate in *Spring's* Transaction >>>>> Management when your @Service components are demarcated with *Spring* >>>>> @Transaction annotations. SDG can sync Geode with *Spring* >>>>> Transactions (either local Cache or Global GTA). See here... >>>>> http://docs.spring.io/spring-data-gemfire/docs/curre >>>>> nt/reference/html/#apis:tx-mgmt >>>>> >>>>> 3. Finally, SDG shields your application from Geode API breaking >>>>> changes. If the Geode API changes, then only the GemfireTemplate >>>>> need change under-the-hood. >>>>> >>>>> There are other subtle advantages here, but the above represents the >>>>> main ones. >>>>> >>>>> Hope this helps. >>>>> >>>>> Cheers, >>>>> John >>>>> >>>>> >>>>> On Fri, Jan 13, 2017 at 11:39 AM, Udo Kohlmeyer <[email protected] >>>>> > wrote: >>>>> >>>>>> Hi Amit, >>>>>> >>>>>> Have you looked at this yet? >>>>>> >>>>>> http://docs.spring.io/spring-data-gemfire/docs/current/refer >>>>>> ence/html/#gemfire-repositories.executing-queries >>>>>> >>>>>> --Udo >>>>>> >>>>>> >>>>>> On 1/13/17 11:30, Amit Pandey wrote: >>>>>> >>>>>>> Hi Guys, >>>>>>> >>>>>>> How can I query regions with Spring Gemfire? >>>>>>> >>>>>>> Regards >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> -John >>>>> john.blum10101 (skype) >>>>> >>>> >>>> >>> >> > > > -- > -John > john.blum10101 (skype) >
