Hi there Parin,
The current CacheLoader implementation is based upon that you, the user,
know what data you are looking for. You then look that data up via a "get".
Even if one could implement a CacheLoader to achieve what you would
like, I believe the biggest problem that would be faced is that you
would never know HOW much data will have to be loaded.
The CacheLoader would now require a separate query for the backing
store, which it would have to run to query the data. Which means, you
effectively will have to run that query against the backing store EVERY
time you run the OQL query, as you would never 100% assured that you
have all the data.
Which now means, you may then just run the query against the backing
store rather than running OQL against GEODE. So, now, the query is as
fast as its slowest member, which would be your backing store.
--Udo
On 8/26/17 23:20, Parin dazz wrote:
Thanks John!
I agree about it. But my concern is more from use case point of view.
If you look @ the use cases I described, it makes more sense now a
days to go for *_Case2_* when people are looking for quick time to
market with QueryService/FunctionService.
Do you think any thing better can be done internally in GEODE
[EXPERIMENTAL in FUTURE] with "*_RegionMetaModel and OQL Parser_*" to
internally invoke cache loader to get what is missing in cache?
Of course, not completely on random fields but configurable
fields/indexed fields/fields well known in advance for which to do
such dynamic loading from external datasource to cache.
Regards,
Parin
On Sun, Aug 27, 2017 at 12:22 AM, John Blum <[email protected]
<mailto:[email protected]>> wrote:
OQL queries do not invoke CacheLoaders.
On Sat, Aug 26, 2017 at 12:01 AM, Parin dazz
<[email protected] <mailto:[email protected]>> wrote:
Hi Folks,
I have some concerns about CacheLoader.
I know that we attach it with the region definition in server
which helps to load missing entries into cache from database.
But my reason for asking is more from usability point of view.
As an example,
Usually in client/server topology, you write a logic @ client
layer to address business queries from users via rest call and
internally contacting gemfire server using 1 of the following
ways,
- QueryService
- FunctionService
- GemfireTemplate
- Repositories
- Direct region level apis [May be not preferable as it does
not provide abstraction as QueryService/FunctionService]
*_Case1:_*
> *_Assuming that I am coding each separate method/api for
each unique business call._*
findStudentById,findStudentByNameAndAge,findStudentWithHomeworkNotCompleted
etc.
Internally each of them is using
GemfireTemplate/Region/Repositories to get the data I need.
>> But does that really make sense to adopt "method/logic per
business query"?
>> Who likes code change for each such new requirement?
>> It's not even wise to write separate function and deploy
jar using "deploy" function as still that needs new code
*_Case2:_*
> *_How about using QueryService/FunctionService where you
define each unique business query in database/query
region/external file/anything_*?
For each new business call, I just have to add new query to my
database in form of "findStudentById = "Select * from /Student
where id=$1"
Ohh yes it has become super easy now to reach time to market
and no change in code.
Assume that I have a nice generic way to deal with dynamic
binding of parameters and their datatypes.
*But now what's the use of "CacheLoader"? *
*
*
*Is it going to work with Gemfire OQL query? May be not as it
does not know if dynamic binding is a "Primary Key" and going
to return only 1 value.*
*
*
*Please share your thoughts. Do also suggest me if there is
better way to achieve same.*
Thanks,
Parin
--
-John
john.blum10101 (skype)
