ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dsetrakyan <dsetrak...@apache.org>
Subject RE: Continuous Query
Date Sat, 09 May 2015 16:22:22 GMT
Andrey Kornev wrote
> Sorry, I accidentally pressed a wrong button. So, as promised, one more
> last thing.
> 
> For materialized view maintenance it's important to know not only when an
> entry gets created/deleted/removed, but also when it comes in and goes out
> of "focus".
> 
> For example, when a cache entry gets updated to the effect so it is now
> passes the CQ filter, the CQ listener should as result be delivered an
> "in-focus" event rather than "created". It would be incorrect to indicate
> the event as "updated" either, because the listener has never seen the
> "created" event for this entry to start with. Besides, special semantics
> may be associated with the act of "creation" of an entry (like a new user
> has been added to the system) vs. just an "update" that has caused the
> entry to become visible to this CQ instance (the user got his permissions
> attribute updated and now should be included in a CQ that is tracking all
> admins, for example).
> 
> Similarly, when a cache entry gets updated so that it no longer matches
> the filter, the listener must be notified of the fact by delivering an
> "out-of-focus" event so it can retract the corresponding state from the
> view.  It might be possible to piggyback on the "deleted" event, but as
> with the "in-focus" above, the specific event would work better.
> 
> In either case, this means that the filter should be applied to both the
> old and the new values for each entry update event. The users could of
> course implement these checks in their code themselves, but once the check
> is done, it doesn't seem there is any way to propagate its result (the
> computed event type) from the filter to the listener.
> 
> Basically, this is just another argument in favor of having a dedicated CQ
> listener interface. The filter interface would also need to
> redesigned/replaced with a GG-specific, since a single boolean return
> value allowed by JCache Filter API is not sufficient to adequately report
> the outcome of the evaluation. In general, JCache's cache listener and
> cache filter APIs are not well suited for the CQ use case and should be
> replaced by richer specialized interfaces.

I think I see your point, especially with out-of-focus use-case. However, I
would like to avoid additional listeners and keep the API backward
compatible. There must be a way to fix it within the current API. I will
think about it and propose something.

I have filed the ticket in Jira,  IGNITE-887
<https://issues.apache.org/jira/browse/IGNITE-887>  . Please feel free to
comment there.


Andrey Kornev wrote
> That's it! It didn't hurt a bit, did it!? :)

Well, let's see how we feel after we implement your suggestions :)




--
View this message in context: http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-Query-tp136p468.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Mime
View raw message