Re: [incquery-dev] Model modification - local search vs RETE

[Ujhelyi Zoltán <ujhelyiz@xxxxxxxxxxxxxxxx>]

Hi,

my answers are inline.


> On 09 Sep 2015, at 08:31, István Ráth <rath@xxxxxxxxxx> wrote:
> 
> Hi,
> 
> I was trying to find the “official” documentation on queries/scopes vs. cross-resource references, but couldn’t immediately find them on https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API nor on https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/API/Advanced. (By the way: to what degree are these pages outdated w.r.t. 1.0.0?) Does anyone know where it is / should be?
I don’t think such a documentation exists (maybe outside of Javadoc). We have a very old ticket corresponding to some issues even we have found here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398907

> 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?
Yes, it is based on the containment hierarchy, and since 1.0 we also support multiple model roots here + filtering there.

The problem here is that navigating happens _very_ often, so adding a containment check for each of these can add up to be expensive (depending on the depth of the containment hierarchy). There are cases when this can be executed cheaply (e.g. when the target type is indexed in Base), but not in general. If multiple model roots are enabled together with filtering, this check becomes even more expensive...

Maybe a post-search filtering is more feasible, but I have my doubts there as well.

> 
> 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.
I guess, this is the main question of the previously linked bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=398907

Cheers,
Zoli
-- Zoltán Ujhelyi

Technology Expert
IncQueryLabs Ltd.