You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by Amit Pandey <am...@gmail.com> on 2017/01/13 19:30:35 UTC
Querying Regions with Spring Gemfire
Hi Guys,
How can I query regions with Spring Gemfire?
Regards
Re: Querying Regions with Spring Gemfire
Posted by John Blum <jb...@pivotal.io>.
Cool beans! Glad that is working for you Amit.
On Sat, Jan 21, 2017 at 6:24 AM, Amit Pandey <am...@gmail.com>
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 <am...@gmail.com>
> 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 <jb...@pivotal.io> 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 <am...@gmail.com>
>>> 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 <amit.pandey2103@gmail.com
>>>> > 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 <
>>>>> amit.pandey2103@gmail.com> 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 <jb...@pivotal.io> 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 <
>>>>>>> ukohlmeyer@pivotal.io> 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)
Re: Querying Regions with Spring Gemfire
Posted by Amit Pandey <am...@gmail.com>.
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 <am...@gmail.com>
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 <jb...@pivotal.io> 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 <am...@gmail.com>
>> 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 <am...@gmail.com>
>>> 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 <amit.pandey2103@gmail.com
>>>> > 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 <jb...@pivotal.io> 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 <
>>>>>> ukohlmeyer@pivotal.io> 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)
>>
>
>
Re: Querying Regions with Spring Gemfire
Posted by Amit Pandey <am...@gmail.com>.
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 <jb...@pivotal.io> 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 <am...@gmail.com>
> 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 <am...@gmail.com>
>> 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 <am...@gmail.com>
>>> 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 <jb...@pivotal.io> 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 <ukohlmeyer@pivotal.io
>>>>> > 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)
>
Re: Querying Regions with Spring Gemfire
Posted by John Blum <jb...@pivotal.io>.
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 <am...@gmail.com>
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 <am...@gmail.com>
> 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 <am...@gmail.com>
>> 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 <jb...@pivotal.io> 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/reference/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 <uk...@pivotal.io>
>>>> 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)
Re: Querying Regions with Spring Gemfire
Posted by Amit Pandey <am...@gmail.com>.
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 <am...@gmail.com>
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.
> getLocalDataForContext(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 <am...@gmail.com>
> 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 <jb...@pivotal.io> 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/reference/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/current/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 <uk...@pivotal.io>
>>> 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)
>>>
>>
>>
>
Re: Querying Regions with Spring Gemfire
Posted by Amit Pandey <am...@gmail.com>.
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.getLocalDataForContext(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 <am...@gmail.com>
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 <jb...@pivotal.io> 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/reference/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/current/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 <uk...@pivotal.io>
>> 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)
>>
>
>
Re: Querying Regions with Spring Gemfire
Posted by Amit Pandey <am...@gmail.com>.
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 <jb...@pivotal.io> 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/reference/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/current/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 <uk...@pivotal.io>
> 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)
>
Re: Querying Regions with Spring Gemfire
Posted by John Blum <jb...@pivotal.io>.
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/reference/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/current/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 <uk...@pivotal.io>
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)
Re: Querying Regions with Spring Gemfire
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
Hi Amit,
Have you looked at this yet?
http://docs.spring.io/spring-data-gemfire/docs/current/reference/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