Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [viatra-dev] IncQuery-related change in the concrete syntax of the CEP Language

Hi,

So, if we wish to direct the development of the VIATRA-CEP engine towards CDTs
I don't think we should go this direction considering the framework's current level of maturity. Although, I completely agree with your last paragraph. And if I understand it correctly, case 2b ("QueryResultChangeEvent") is something IQPatternEvents currently cover, so maybe this could be its new name. That would allow extending the set of detectable change events in the future in accordance with the categories you just mentioned.
Should we go then with the IQPatternEvents->QueryResultChangeEvent renaming?

Cheers,
Istvan


2015-01-18 14:46 GMT+01:00 István Ráth <rath@xxxxxxxxxx>:

On 18 Jan 2015 at 00:20:39, David, Istvan (davidi@xxxxxxxxxxxxxx) wrote:

Therefore, I think this element should be renamed to either ModelEvent or maybe ModelChangeEvent. I prefer the former one, since terms like "change", "evolution", "modification", etc are often used interchangeably and we might end up with another misleading keyword.
What do you think?

I see your point in general, however replacing “IQPatternEvent” with “ModelChangeEvent” might just as well be misleading.

“IQPatternEvent” represents a “change in the result set of a query” event, which is only indirectly related to model changes. Result set changes can even be induced in scenarios when models are not manipulated at all, e.g. if a new resource is loaded into a resourceset (on which a query has been initialized with the ResourceSet scope).

Further, “ModelChangeEvent”, to me, represents an event on a lower level of abstraction, i.e. the level of elementary model changes (notifications: ADD, REMOVE, etc); which, by the way, could also be interesting for CDTs. So, if we wish to direct the development of the VIATRA-CEP engine towards CDTs, one could argue that instead of renaming the construct, we actually need to extend detectable change events to 1) atomic change operations (“ModelChangeEvent”) 2) compound changes that can either be 2a) complete transactions (“ModelChangeTransactionEvent”) or 2b) query result set changes (“QueryResultChangeEvent”).

cheers


-- 
István Ráth
Research Fellow
Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

_______________________________________________
viatra-dev mailing list
viatra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/viatra-dev


Back to the top