let's keep this on -dev.
On Oct 17, 2013, at 6:24 PM, Sanne Grinovero <[email protected]> wrote:
> ----- Original Message -----
>>
>> On Oct 17, 2013, at 2:28 PM, Sanne Grinovero <[email protected]> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>>> On Oct 17, 2013, at 1:31 PM, Sanne Grinovero <[email protected]> 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
_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
