agingade commented on pull request #5774: URL: https://github.com/apache/geode/pull/5774#issuecomment-818319699
I have added following comments in the ticket also: I have to look into the PR to see what your are really are trying to achieve in this ticket. It will be helpful if you can add more information with the example (depending on the issue). E.g. Avoid sending CQ events for specific CQ query-operations (E.g. destroy Query operation) to client. For a region.put() which results in CQ event with its query operation as destroy; avoid sending this event to client. I am not seeing any value/scenario that needs this kind of behavior. Do you have any example can you please explain here. The core CQ design aspect was to establish a data view representing a query result that can be expressed in the form of query. And support event mechanism that will enable to manage/maintain that view as the change happens on the source data. The changes requested in this ticket, breaks the core design and can allow one to represent/establish a different data view that is not in-line with the source data (a query result view). I don't see need for supporting that kind of behavior in the server side. If Client is not interested to see specific event/operation it should be filtering this out on the client side. Why the need for this behavior? Looking the Pull Request opened; its not like its avoiding processing of CQs, which is generally more expensive part of having CQ; only thing its avoiding sending the CQ event to client. If this is the behavior client/application is looking for; probably CQ is not the functionality to use. Also, it will be nice to use Request For Change (RFC) process for any issues that has behavior/functional or new API requirements. It will help to get feedback during design phase itself. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
