Cool beans! Glad that is working for you Amit. On Sat, Jan 21, 2017 at 6:24 AM, Amit Pandey <[email protected]> wrote:
> 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/PeerCacheFunc >>> tionExecutionUsingRepositoryOnFilteredLocalDataSetTest.java >>> [3] https://github.com/jxblum/spring-gemfire-tests/blob/mast >>> er/src/main/java/org/spring/data/gemfire/app/dao/repo/Progra >>> mmerRepository.java >>> [4] https://github.com/jxblum/spring-gemfire-tests/blob/mast >>> er/src/main/java/org/spring/data/gemfire/cache/execute/Progr >>> ammerFunctions.java >>> [5] http://docs.spring.io/spring-data-gemfire/docs/current/r >>> eference/html/#function-annotations >>> [6] https://github.com/jxblum/spring-gemfire-tests/blob/mast >>> er/src/main/java/org/spring/data/gemfire/app/dao/repo/suppor >>> t/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) >>> >> >> > -- -John john.blum10101 (skype)
