Sorry thanks it works, there are two of the class I accidentally imported in the *.internal* one.
Regards On Sat, Jan 21, 2017 at 7:52 PM, Amit Pandey <[email protected]> wrote: > 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.g >> etLocalDataForContext(: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.getLocalDataSetForCo >> ntext(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/mast >> er/src/test/java/org/spring/data/gemfire/cache/PeerCacheFu >> nctionExecutionUsingRepositoryOnFilteredLocalDataSetTest.java >> [3] https://github.com/jxblum/spring-gemfire-tests/blob/mast >> er/src/main/java/org/spring/data/gemfire/app/dao/repo/ >> ProgrammerRepository.java >> [4] https://github.com/jxblum/spring-gemfire-tests/blob/mast >> er/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/mast >> er/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) >> > >
