Hi,
Anyway, I think the behavior of LS and Rete should be functionally equivalent, i.e. both should respect the matching scope according to the same semantics. In other words, an EObject should only be returned in the match set iff it is considered to be part of the scope of the matcher. As far as I know, our scope definition currently does rely on the containment hierarchy (as highlighted by your findings).
So in the short term, LS should also follow this. I’m not sure about the performance impact though - I guess this is just an additional check when navigating relations and easy to measure in terms of overhead. Could you do this?
In the longer term however, maybe we can consider introducing an additional flag to relax this, however my gut feeling is that this is really only feasible for non-Base-indexer LS configurations - Gaben correct me if I’m wrong.
cheers Istvan
On 8 Sep 2015 at 23:45:59, Ujhelyi Zoltán (ujhelyiz@xxxxxxxxxxxxxxxx) wrote: HI,
some minor clarification (before Gaben comes home correcting it :) ): if an element is removed from the containment hierarchy (without the use of EcoreUtil.delete), it is possible that there is still a cross-reference (non-containment) pointing to it. After that point the Base indexer/Rete does not consider this EObject indexed (thus will not part of any match set). On the other hand, local search may find this node via these cross-references (but it is not guaranteed, asit might rely on Base to reach that instance).
The main question/challange here is what to do with the inconsistency:
1. Ignore it and tell all users not to provide such cases (problematic as we have a large base of existing code we want to be compatible with :) )
2. Document it that here might be some issues, and live with the fact that the two engines are not equivalent
3. Make sure that all results are still in the original containment hierarchy (depending on the model/indexer setup this may worsen performance)
4. Something else I don’t see as clearly.
Sadly, none of my alternatives sound good to me, but I am/we are open to ideas…
Cheers,
Zoli
-- Zoltán Ujhelyi
Technology Expert
IncQueryLabs Ltd.
> On 08 Sep 2015, at 23:33, Márton Búr <marton.bur@xxxxxxxxx> wrote:
>
> Dear All,
>
> Today I ran into a problem, which is worth mentioning. I was running all the School tests to see the new local search algorithm (not yet merged into master) performing. Except for the recursive patterns, all other tests but two were passing. The two failures were caused by unexpected matches.
> The problem briefly: local search based matcher is not considered* about the EMF notifications, however RETE matcher is. This difference may result in different matching results, especially in cases when the model is modified subsequently.
> I provided some details about this issue on page https://wiki.eclipse.org/EMFIncQuery/DeveloperDocumentation/LocalSearch under KnownProblems.
>
> Cheers,
> Marci
>
> *this statement is basically true, when the matcher does not use the base index
> _______________________________________________
> incquery-dev mailing list
> incquery-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/incquery-dev
_______________________________________________
incquery-dev mailing list
incquery-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/incquery-dev
--
István Ráth
Research Fellow Fault Tolerant Systems Research Group Budapest University of Technology and Economics http://inf.mit.bme.hu/en/members/rath rath@xxxxxxxxxx |
