let's keep this on -dev.
On Oct 17, 2013, at 6:24 PM, Sanne Grinovero <sanne(a)redhat.com> wrote:
----- Original Message -----
>
> On Oct 17, 2013, at 2:28 PM, Sanne Grinovero <sanne(a)redhat.com> wrote:
>
>>
>>
>> ----- Original Message -----
>>> On Oct 17, 2013, at 1:31 PM, Sanne Grinovero <sanne(a)redhat.com> wrote:
>>>
>>>> With some custom coding it's certainly possible to define an event
>>>> listener
>>>> which triggers when an entry is inserted/removed which matches a certain
>>>> Query.
>>>
>>> where would hold the the query result? a cache perhaps?
>>
>> Why do you need to hold on to the query result?
>> I was thinking to just send an event "newly stored X matches query
Q1".
>
> You don't have a single process receive all the notifications then, but
> multiple processes in the cluster. It's up to the user to aggregate these
> results (that's why I mentioned a cache) but without aggregation this
> feature is pretty limiting.
I have no idea if it's limiting. For the use case I understood, that's pretty
decent.
Here's my understanding of CQ[1]: a user queries a cache 10000000( you add the rest of
0) per second.
Instead of executing the query every time (very resource consuming) the system caches the
query result, update it when underlying data gets modified, and return to the user on
every invocation. Optionally you can register a listener on the query result, but
that's just API sugar.
>> You could register multiple such listeners, getting the effect of "newly
>> stored entry X matches Query set {Q1, Q3, Q7}"
>
> The listeners would not be collocated.
I'm not going to implement distributed listeners, I indeed expect you to register
such a listener on each node.
If I run a query, continuous or not, I'd expect to be able to get all the result set
of that query on the process on which I invoke it. Call me old fashion :-)
I can show how to make Continous Queries on the Query API to accomplish this.
I wouldn't name the problem your solution solve Continuous Query :-)
Anything else is out of scope for me :-) Technically I think it's
out of scope for Infinispan too, it should delegate to a message bus.
-1, for the reasons mentioned above.
[1]
http://coherence.oracle.com/display/COH31UG/Continuous+Query