Eclipse Community Forums: EMF » Issues with collectReachableObjectsOfType

Help

Home

Home » Modeling » EMF » Issues with collectReachableObjectsOfType

Show: Today's Messages :: Show Polls :: Message Navigator

Issues with collectReachableObjectsOfType [message #631727]

Fri, 08 October 2010 13:55

Alain Picard

Messages: 233
Registered: July 2009

Senior Member

As discussed by others a few years ago, collectReachableObjectsOfType is
aggressively looking at the whole model, and when dealing with a "root"
model that manages proxy references to a set of very huge models, this
forces the loading of the whole graph, which can be millions of objects
(over 14 millions reported from YourKit in my case) from all the
referenced models.

I probably can turn off the resolve proxy and that might avoid this
situation, but that would force us to revise some of the code that
expects on-demand loading of those models (1 by 1 normally, never all of
them).

But in looking at the current collectReachableObjectsOfType, I can't
understand why it needs to visit the whole graph.

I have a reference feature point to class C which extends class B and
class A has a containment relation to class B.

X --has feature --> Y
Y --reference of type --> C

C --extends --> B
A --containment to --> B

So the only way to get to C is to get the containment list of A and
filter those elements which are of type C (not other subtypes of B).

So why can't collectReachableObjectsOfType actually apply such logic
instead of looking at tons of unrelated objects?

Thanks for helping me understand here.

Alain

Report message to a moderator

Re: Issues with collectReachableObjectsOfType [message #631753 is a reply to message #631727]

Fri, 08 October 2010 15:43

Ed Merks

Messages: 30551
Registered: July 2009

Senior Member

Alain,

Comments below.

Alain Picard wrote:
> As discussed by others a few years ago, collectReachableObjectsOfType
> is aggressively looking at the whole model, and when dealing with a
> "root" model that manages proxy references to a set of very huge
> models, this forces the loading of the whole graph, which can be
> millions of objects (over 14 millions reported from YourKit in my
> case) from all the referenced models.
>
> I probably can turn off the resolve proxy and that might avoid this
> situation, but that would force us to revise some of the code that
> expects on-demand loading of those models (1 by 1 normally, never all
> of them).
>
> But in looking at the current collectReachableObjectsOfType, I can't
> understand why it needs to visit the whole graph.
Objects of the right type can be lurking anywhere.
>
> I have a reference feature point to class C which extends class B and
> class A has a containment relation to class B.
>
> X --has feature --> Y
> Y --reference of type --> C
>
> C --extends --> B
> A --containment to --> B
>
> So the only way to get to C is to get the containment list of A and
> filter those elements which are of type C (not other subtypes of B).
Of course anyone can subtype any of these classes and introduce features
that make it possible reach objects of types you might not expect just
looking at the base model.
>
> So why can't collectReachableObjectsOfType actually apply such logic
> instead of looking at tons of unrelated objects?
Because of open ended derivation, there's no way to guarantee that you
can't reach objects of any particular type.
>
> Thanks for helping me understand here.
I think only if your domain is bounded can you apply this type of
analysis. I.e., if you know all EClass that might be used in the
instance, you could determine the possibility of reachability by the
analysis you've outlined.
>
> Alain
>
>

Report message to a moderator

Re: Issues with collectReachableObjectsOfType [message #631774 is a reply to message #631753]

Fri, 08 October 2010 17:10

Alain Picard

Messages: 233
Registered: July 2009

Senior Member

Ed,

> Objects of the right type can be lurking anywhere.
> Because of open ended derivation, there's no way to guarantee that you
> can't reach objects of any particular type.

Ok, I get that this is possible, but wouldn't it be better and faster to
analyze the base and reachable model(s) and identify if they indeed
subtype the type in question and if they do then if there is some
containment that can be followed. This metadata introspection can be
used to prepare an "intelligent query plan" and to skip it all together
if the plan shows no such possibilities in external models. In all cases
it would be faster to analyze the meta-models than to brute force
ourselves through the models. Or are we looking to find "EObject"
attributes to be able to contain anything and everything here?

Thanks
Alain

Report message to a moderator

Re: Issues with collectReachableObjectsOfType [message #631802 is a reply to message #631774]

Fri, 08 October 2010 20:01

Ed Merks

Messages: 30551
Registered: July 2009

Senior Member

Alain,

Comments beow.

Alain Picard wrote:
> Ed,
>
>> Objects of the right type can be lurking anywhere.
>> Because of open ended derivation, there's no way to guarantee that you
>> can't reach objects of any particular type.
>
> Ok, I get that this is possible, but wouldn't it be better and faster
> to analyze the base and reachable model(s) and identify if they indeed
> subtype the type in question and if they do then if there is some
> containment that can be followed. This metadata introspection can be
> used to prepare an "intelligent query plan" and to skip it all
> together if the plan shows no such possibilities in external models.
> In all cases it would be faster to analyze the meta-models than to
> brute force ourselves through the models. Or are we looking to find
> "EObject" attributes to be able to contain anything and everything here?
Suppose we have some EObject x whose class is X and that class has a
containment reference foo to class Y. Until I do o.eGet(foo) and look
at the EClass of the result, I won't know if it's a Y or some class Z
derived from Y and it might well be the case that given X and Y there's
no way to no that Z exists. It could be in some model I don't know
about yet. So it gets back to my comment about an analysis being
definitive only if you know all possible classes you might encounter.
I imagine for many clients you really would know that this set of
packages is all I use in my application. It would certainly be
interesting to explore to how exploit that for more efficient visiting...
>
> Thanks
> Alain

Report message to a moderator

Re: Issues with collectReachableObjectsOfType [message #631817 is a reply to message #631802]

Fri, 08 October 2010 21:31

Alain Picard

Messages: 233
Registered: July 2009

Senior Member

On 10/8/2010 4:01 PM, Ed Merks wrote:
> So it gets back to my comment about an analysis being definitive
> only if you know all possible classes you might encounter. I imagine for
> many clients you really would know that this set of packages is all I
> use in my application. It would certainly be interesting to explore to
> how exploit that for more efficient visiting...

IMHO, this is one of the good reason why we do modeling in the first
place and is probably the "normal" use case. That being said I
understand how some cases can stretch this and where the current
approach is the only fully safe one in all cases, but surely not the
generally most efficient (or even usable as our case shows).

Alain

Report message to a moderator

Re: Issues with collectReachableObjectsOfType [message #631828 is a reply to message #631817]

Fri, 08 October 2010 22:41

Ed Merks

Messages: 30551
Registered: July 2009

Senior Member

Alain,

Comments below.

Alain Picard wrote:
> On 10/8/2010 4:01 PM, Ed Merks wrote:
>> So it gets back to my comment about an analysis being definitive
>> only if you know all possible classes you might encounter. I imagine for
>> many clients you really would know that this set of packages is all I
>> use in my application. It would certainly be interesting to explore to
>> how exploit that for more efficient visiting...
>
> IMHO, this is one of the good reason why we do modeling in the first
> place and is probably the "normal" use case.
The code that does the visiting doesn't know all models until it visits
all objects. And even then, it doesn't know that the next time it
visits the objects, that there won't be yet more new models. Keep in
mind that this code is used even in cases where models are dynamically
loaded...
> That being said I understand how some cases can stretch this and where
> the current approach is the only fully safe one in all cases, but
> surely not the generally most efficient (or even usable as our case
> shows).
The current approach is the only fully general one. But as I said, it
would definitely be interesting to explore support for the case of a
bounded set of packages. It's definitely something that modeling makes
possible!
>
> Alain

Report message to a moderator

Previous Topic:	ChangeRecorder: Ignore Notifications of Transient EStructuralFeatures
Next Topic:	RAP Version of EM Transaction and EMF Validation

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat Oct 19 10:42:41 GMT 2019

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter