Home » Modeling » EMF » Proxies for Containment Features?
| |
| Re: Proxies for Containment Features? [message #388846 is a reply to message #388842] |
Wed, 27 October 2004 17:16   |
 Chris McGee
Messages: 99
Registered: July 2009 |
Member |
|
|
Hi Marcelo,
That makes sense.
If all features were non-containment features then we could place the
referenced objects wherever we want. Well, not quite. We'd have to find
another appropriate feature to place the objects or put them at the root
of the resource. I believe that having multiple root objects of a resource
is not allowed in the current XMIResource implementation.
One of the problems in our situation is that our metamodel specifications
give us the features that should be containment. Our XMI is expected to
conform to this as much as possible. So, it's not an option to have a
whole bunch of XML elements at the root of the document even if the
resource would allow it.
What we'd need is to have two features(containment and non-containment) to
contribute to one parent feature. The parent feature would simply derive
its result from the union of the two children features. At an API level,
the developer could decide which of the three features is appropriate for
their EObject. If the developer chose to locate the EObject elsewhere,
they could create a new resource and place that EObject as the root of the
other resource.
The parent feature would have to be made read-only so that the storage
location is not ambiguous if someone tried to add a new EObject to the
list.
Maybe an extended code generator plus some extra data in our metamodel
could create the three features automatically with some default naming
scheme: getContainedBlahs(), getReferencedBlahs() and getBlahs()(read-only
and derived)?
Chris
Marcelo Paternostro wrote:
> The containment reference has a very specific meaning. As an example, from
> a modeling perspective it implies that the container "requires" its children
> to "exist". Splitting the file would introduce the chance of having an
> incomplete object so I don't believe we will be able to implement your
> suggestion.
> That said, why are you using a containment reference if it doesn't fit your
> requirements?
> Regards,
> Marcelo.
> "Chris McGee" <cbmcgee@ca.ibm.com> wrote in message
> news:clo5co$s5u$1@eclipse.org...
> > Hi All,
> >
> > I am working with a project that is built on top of EMF. I often come in
> > contact with EMF models when I am developing various tools.
> >
> > One problem that we keep hitting with our project is memory performance.
> > Unfortunately, our metamodel is large (large in the number of EClasses and
> > large in the number of features defined on each EClass). It's not unusual
> > to encounter situations where we have to load XMIResource's whose source
> > file would be 10's or even 100's of megabytes.
> >
> > I have an idea I thought I would just give out to see if it is practical
> > for the next EMF release. I know that whenever an inter-resource
> > bi-directional reference is made through a non-containment feature, the
> > two ends get serialized as proxies (at least with the XMIResource).
> > Whenever each of the models is loaded by XMIResource, the proxies are left
> > in memory until they are resolved. The resolution could force the loading
> > of the other resource using the URI stored in the proxy. If the reference
> > is bi-directional then either resource could load the other if either of
> > the two proxies is being resolved.
> >
> > Couldn't something similar be used in containment features? Containment
> > features are inherently bi-directional because the child knows about its
> > parent by eContainer() and the parent knows about the child through the
> > containment feature. That way the child could be placed into a separate
> > resource and only loaded on-demand. This would allow anyone working with
> > very large resources to split them up and only load portions of the
> > resource when necessary.
> >
> > Just a thought,
> >
> > Chris McGee
> >
|
|
|
| Re: Proxies for Containment Features? [message #388848 is a reply to message #388846] |
Wed, 27 October 2004 18:46 |
Marcelo Paternostro
Messages: 602
Registered: July 2009 |
Senior Member |
|
|
Hi Chris,
The XMIResource can have multiple roots but, as you've mentioned, this won't
help in your case.
I had a similar problem a while ago and was able to solve it by changing the
model by introducing an "artificial" container for the objects that I had to
store in a separate file - one can argue that this is a valid design change
;-). So instead of having an association by value (solid diamond) between
classA and classB, I've ended up with an association by reference (white
diamond) between classA and classBContainer and an association by value
between classBContainer and classB.
If you are planning to dig into "combining features" I would recommend you
to read Frank's article describing FeatureMap which is available on our
"Documents" page. The link to the document is
http://dev.eclipse.org/viewcvs/indextools.cgi/%7Echeckout%7E /emf-home/docs/overviews/FeatureMap.pdf
Cheers,
Marcelo
"Chris McGee" <cbmcgee@ca.ibm.com> wrote in message
news:clol5c$1i0$1@eclipse.org...
> Hi Marcelo,
>
> That makes sense.
>
> If all features were non-containment features then we could place the
> referenced objects wherever we want. Well, not quite. We'd have to find
> another appropriate feature to place the objects or put them at the root
> of the resource. I believe that having multiple root objects of a resource
> is not allowed in the current XMIResource implementation.
>
> One of the problems in our situation is that our metamodel specifications
> give us the features that should be containment. Our XMI is expected to
> conform to this as much as possible. So, it's not an option to have a
> whole bunch of XML elements at the root of the document even if the
> resource would allow it.
>
> What we'd need is to have two features(containment and non-containment) to
> contribute to one parent feature. The parent feature would simply derive
> its result from the union of the two children features. At an API level,
> the developer could decide which of the three features is appropriate for
> their EObject. If the developer chose to locate the EObject elsewhere,
> they could create a new resource and place that EObject as the root of the
> other resource.
>
> The parent feature would have to be made read-only so that the storage
> location is not ambiguous if someone tried to add a new EObject to the
> list.
>
> Maybe an extended code generator plus some extra data in our metamodel
> could create the three features automatically with some default naming
> scheme: getContainedBlahs(), getReferencedBlahs() and getBlahs()(read-only
> and derived)?
>
> Chris
>
> Marcelo Paternostro wrote:
>
> > The containment reference has a very specific meaning. As an example,
from
> > a modeling perspective it implies that the container "requires" its
children
> > to "exist". Splitting the file would introduce the chance of having an
> > incomplete object so I don't believe we will be able to implement your
> > suggestion.
>
> > That said, why are you using a containment reference if it doesn't fit
your
> > requirements?
>
> > Regards,
> > Marcelo.
>
>
> > "Chris McGee" <cbmcgee@ca.ibm.com> wrote in message
> > news:clo5co$s5u$1@eclipse.org...
> > > Hi All,
> > >
> > > I am working with a project that is built on top of EMF. I often come
in
> > > contact with EMF models when I am developing various tools.
> > >
> > > One problem that we keep hitting with our project is memory
performance.
> > > Unfortunately, our metamodel is large (large in the number of EClasses
and
> > > large in the number of features defined on each EClass). It's not
unusual
> > > to encounter situations where we have to load XMIResource's whose
source
> > > file would be 10's or even 100's of megabytes.
> > >
> > > I have an idea I thought I would just give out to see if it is
practical
> > > for the next EMF release. I know that whenever an inter-resource
> > > bi-directional reference is made through a non-containment feature,
the
> > > two ends get serialized as proxies (at least with the XMIResource).
> > > Whenever each of the models is loaded by XMIResource, the proxies are
left
> > > in memory until they are resolved. The resolution could force the
loading
> > > of the other resource using the URI stored in the proxy. If the
reference
> > > is bi-directional then either resource could load the other if either
of
> > > the two proxies is being resolved.
> > >
> > > Couldn't something similar be used in containment features?
Containment
> > > features are inherently bi-directional because the child knows about
its
> > > parent by eContainer() and the parent knows about the child through
the
> > > containment feature. That way the child could be placed into a
separate
> > > resource and only loaded on-demand. This would allow anyone working
with
> > > very large resources to split them up and only load portions of the
> > > resource when necessary.
> > >
> > > Just a thought,
> > >
> > > Chris McGee
> > >
>
>
|
|
|
| Re: Proxies for Containment Features? [message #388855 is a reply to message #388846] |
Wed, 27 October 2004 20:20 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------080408020301070308030001
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Chris,
The main problem with proxies for containment is that the Resource is
considered a container, so adding an object directly to
Resource.getContents will remove it from whatever container is currently
holding it, either some other EObject or some other Resource. So if you
had a proxy to some object contained by some other resource, when you
resolve it and put in into the containment feature, you would be
removing it from that other resource.
Chris McGee wrote:
>Hi Marcelo,
>
>That makes sense.
>
>If all features were non-containment features then we could place the
>referenced objects wherever we want. Well, not quite. We'd have to find
>another appropriate feature to place the objects or put them at the root
>of the resource. I believe that having multiple root objects of a resource
>is not allowed in the current XMIResource implementation.
>
>One of the problems in our situation is that our metamodel specifications
>give us the features that should be containment. Our XMI is expected to
>conform to this as much as possible. So, it's not an option to have a
>whole bunch of XML elements at the root of the document even if the
>resource would allow it.
>
>What we'd need is to have two features(containment and non-containment) to
>contribute to one parent feature. The parent feature would simply derive
>its result from the union of the two children features. At an API level,
>the developer could decide which of the three features is appropriate for
>their EObject. If the developer chose to locate the EObject elsewhere,
>they could create a new resource and place that EObject as the root of the
>other resource.
>
>The parent feature would have to be made read-only so that the storage
>location is not ambiguous if someone tried to add a new EObject to the
>list.
>
>Maybe an extended code generator plus some extra data in our metamodel
>could create the three features automatically with some default naming
>scheme: getContainedBlahs(), getReferencedBlahs() and getBlahs()(read-only
>and derived)?
>
>Chris
>
>Marcelo Paternostro wrote:
>
>
>
>>The containment reference has a very specific meaning. As an example, from
>>a modeling perspective it implies that the container "requires" its children
>>to "exist". Splitting the file would introduce the chance of having an
>>incomplete object so I don't believe we will be able to implement your
>>suggestion.
>>
>>
>
>
>
>>That said, why are you using a containment reference if it doesn't fit your
>>requirements?
>>
>>
>
>
>
>>Regards,
>>Marcelo.
>>
>>
>
>
>
>
>>"Chris McGee" <cbmcgee@ca.ibm.com> wrote in message
>>news:clo5co$s5u$1@eclipse.org...
>>
>>
>>>Hi All,
>>>
>>>I am working with a project that is built on top of EMF. I often come in
>>>contact with EMF models when I am developing various tools.
>>>
>>>One problem that we keep hitting with our project is memory performance.
>>>Unfortunately, our metamodel is large (large in the number of EClasses and
>>>large in the number of features defined on each EClass). It's not unusual
>>>to encounter situations where we have to load XMIResource's whose source
>>>file would be 10's or even 100's of megabytes.
>>>
>>>I have an idea I thought I would just give out to see if it is practical
>>>for the next EMF release. I know that whenever an inter-resource
>>>bi-directional reference is made through a non-containment feature, the
>>>two ends get serialized as proxies (at least with the XMIResource).
>>>Whenever each of the models is loaded by XMIResource, the proxies are left
>>>in memory until they are resolved. The resolution could force the loading
>>>of the other resource using the URI stored in the proxy. If the reference
>>>is bi-directional then either resource could load the other if either of
>>>the two proxies is being resolved.
>>>
>>>Couldn't something similar be used in containment features? Containment
>>>features are inherently bi-directional because the child knows about its
>>>parent by eContainer() and the parent knows about the child through the
>>>containment feature. That way the child could be placed into a separate
>>>resource and only loaded on-demand. This would allow anyone working with
>>>very large resources to split them up and only load portions of the
>>>resource when necessary.
>>>
>>>Just a thought,
>>>
>>>Chris McGee
>>>
>>>
>>>
>
>
>
>
--------------080408020301070308030001
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Chris,<br>
<br>
The main problem with proxies for containment is that the Resource is
considered a container, so adding an object directly to
Resource.getContents will remove it from whatever container is
currently holding it, either some other EObject or some other
Resource.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Proxies for Containment Features? [message #388870 is a reply to message #388855] |
Thu, 28 October 2004 17:50 |
Chris McGee
Messages: 99
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for the information. I think I understand this a bit better now.
Am I right in assuming that the whole reason for containment features is
to complement the EMF resource? Would this be a non-issue if I were
creating a floating set of EObjects using a metamodel with no containment
features?
If I were to mark all features as non-containment but I were to mark some
with some special metadata then I could make my own resource
implementation that would use that criteria to decide containment or not.
To avoid the removal of an EObject from its container I could override
proxy resolution to leave the proxy alone and simply return the EObject
that the proxy resolves to.
Chris
Ed Merks wrote:
> Chris,
> The main problem with proxies for containment is that the Resource is
> considered a container, so adding an object directly to
> Resource.getContents will remove it from whatever container is currently
> holding it, either some other EObject or some other Resource. So if you
> had a proxy to some object contained by some other resource, when you
> resolve it and put in into the containment feature, you would be
> removing it from that other resource.
> Chris McGee wrote:
> >Hi Marcelo,
> >
> >That makes sense.
> >
> >If all features were non-containment features then we could place the
> >referenced objects wherever we want. Well, not quite. We'd have to find
> >another appropriate feature to place the objects or put them at the root
> >of the resource. I believe that having multiple root objects of a resource
> >is not allowed in the current XMIResource implementation.
> >
> >One of the problems in our situation is that our metamodel specifications
> >give us the features that should be containment. Our XMI is expected to
> >conform to this as much as possible. So, it's not an option to have a
> >whole bunch of XML elements at the root of the document even if the
> >resource would allow it.
> >
> >What we'd need is to have two features(containment and non-containment) to
> >contribute to one parent feature. The parent feature would simply derive
> >its result from the union of the two children features. At an API level,
> >the developer could decide which of the three features is appropriate for
> >their EObject. If the developer chose to locate the EObject elsewhere,
> >they could create a new resource and place that EObject as the root of the
> >other resource.
> >
> >The parent feature would have to be made read-only so that the storage
> >location is not ambiguous if someone tried to add a new EObject to the
> >list.
> >
> >Maybe an extended code generator plus some extra data in our metamodel
> >could create the three features automatically with some default naming
> >scheme: getContainedBlahs(), getReferencedBlahs() and getBlahs()(read-only
> >and derived)?
> >
> >Chris
> >
> >Marcelo Paternostro wrote:
> >
> >
> >
> >>The containment reference has a very specific meaning. As an example, from
> >>a modeling perspective it implies that the container "requires" its
children
> >>to "exist". Splitting the file would introduce the chance of having an
> >>incomplete object so I don't believe we will be able to implement your
> >>suggestion.
> >>
> >>
> >
> >
> >
> >>That said, why are you using a containment reference if it doesn't fit your
> >>requirements?
> >>
> >>
> >
> >
> >
> >>Regards,
> >>Marcelo.
> >>
> >>
> >
> >
> >
> >
> >>"Chris McGee" <cbmcgee@ca.ibm.com> wrote in message
> >>news:clo5co$s5u$1@eclipse.org...
> >>
> >>
> >>>Hi All,
> >>>
> >>>I am working with a project that is built on top of EMF. I often come in
> >>>contact with EMF models when I am developing various tools.
> >>>
> >>>One problem that we keep hitting with our project is memory performance.
> >>>Unfortunately, our metamodel is large (large in the number of EClasses and
> >>>large in the number of features defined on each EClass). It's not unusual
> >>>to encounter situations where we have to load XMIResource's whose source
> >>>file would be 10's or even 100's of megabytes.
> >>>
> >>>I have an idea I thought I would just give out to see if it is practical
> >>>for the next EMF release. I know that whenever an inter-resource
> >>>bi-directional reference is made through a non-containment feature, the
> >>>two ends get serialized as proxies (at least with the XMIResource).
> >>>Whenever each of the models is loaded by XMIResource, the proxies are left
> >>>in memory until they are resolved. The resolution could force the loading
> >>>of the other resource using the URI stored in the proxy. If the reference
> >>>is bi-directional then either resource could load the other if either of
> >>>the two proxies is being resolved.
> >>>
> >>>Couldn't something similar be used in containment features? Containment
> >>>features are inherently bi-directional because the child knows about its
> >>>parent by eContainer() and the parent knows about the child through the
> >>>containment feature. That way the child could be placed into a separate
> >>>resource and only loaded on-demand. This would allow anyone working with
> >>>very large resources to split them up and only load portions of the
> >>>resource when necessary.
> >>>
> >>>Just a thought,
> >>>
> >>>Chris McGee
> >>>
> >>>
> >>>
> >
> >
> >
> >
|
|
|
| Re: Proxies for Containment Features? [message #388986 is a reply to message #388870] |
Mon, 01 November 2004 12:38 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------090303030204090709060807
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Chris,
Containment is supported to manage object lifetime. I general, one
should expect an object to live only as long as its container. So if an
object lives in a separate resource, you should expect to be able to
reference in but not to try to contain it. I would not recommend trying
to force the framework to handle "containment" in a different way.
Chris McGee wrote:
>Hi Ed,
>
>Thanks for the information. I think I understand this a bit better now.
>
>Am I right in assuming that the whole reason for containment features is
>to complement the EMF resource? Would this be a non-issue if I were
>creating a floating set of EObjects using a metamodel with no containment
>features?
>
>If I were to mark all features as non-containment but I were to mark some
>with some special metadata then I could make my own resource
>implementation that would use that criteria to decide containment or not.
>To avoid the removal of an EObject from its container I could override
>proxy resolution to leave the proxy alone and simply return the EObject
>that the proxy resolves to.
>
>Chris
>
>Ed Merks wrote:
>
>
>
>>Chris,
>>
>>
>
>
>
>>The main problem with proxies for containment is that the Resource is
>>considered a container, so adding an object directly to
>>Resource.getContents will remove it from whatever container is currently
>>holding it, either some other EObject or some other Resource. So if you
>>had a proxy to some object contained by some other resource, when you
>>resolve it and put in into the containment feature, you would be
>>removing it from that other resource.
>>
>>
>
>
>
>
>>Chris McGee wrote:
>>
>>
>
>
>
>>>Hi Marcelo,
>>>
>>>That makes sense.
>>>
>>>If all features were non-containment features then we could place the
>>>referenced objects wherever we want. Well, not quite. We'd have to find
>>>another appropriate feature to place the objects or put them at the root
>>>of the resource. I believe that having multiple root objects of a resource
>>>is not allowed in the current XMIResource implementation.
>>>
>>>One of the problems in our situation is that our metamodel specifications
>>>give us the features that should be containment. Our XMI is expected to
>>>conform to this as much as possible. So, it's not an option to have a
>>>whole bunch of XML elements at the root of the document even if the
>>>resource would allow it.
>>>
>>>What we'd need is to have two features(containment and non-containment) to
>>>contribute to one parent feature. The parent feature would simply derive
>>>its result from the union of the two children features. At an API level,
>>>the developer could decide which of the three features is appropriate for
>>>their EObject. If the developer chose to locate the EObject elsewhere,
>>>they could create a new resource and place that EObject as the root of the
>>>other resource.
>>>
>>>The parent feature would have to be made read-only so that the storage
>>>location is not ambiguous if someone tried to add a new EObject to the
>>>list.
>>>
>>>Maybe an extended code generator plus some extra data in our metamodel
>>>could create the three features automatically with some default naming
>>>scheme: getContainedBlahs(), getReferencedBlahs() and getBlahs()(read-only
>>>and derived)?
>>>
>>>Chris
>>>
>>>Marcelo Paternostro wrote:
>>>
>>>
>>>
>>>
>>>
>>>>The containment reference has a very specific meaning. As an example, from
>>>>a modeling perspective it implies that the container "requires" its
>>>>
>>>>
>children
>
>
>>>>to "exist". Splitting the file would introduce the chance of having an
>>>>incomplete object so I don't believe we will be able to implement your
>>>>suggestion.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>That said, why are you using a containment reference if it doesn't fit your
>>>>requirements?
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>Regards,
>>>>Marcelo.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>>"Chris McGee" <cbmcgee@ca.ibm.com> wrote in message
>>>>news:clo5co$s5u$1@eclipse.org...
>>>>
>>>>
>>>>
>>>>
>>>>>Hi All,
>>>>>
>>>>>I am working with a project that is built on top of EMF. I often come in
>>>>>contact with EMF models when I am developing various tools.
>>>>>
>>>>>One problem that we keep hitting with our project is memory performance.
>>>>>Unfortunately, our metamodel is large (large in the number of EClasses and
>>>>>large in the number of features defined on each EClass). It's not unusual
>>>>>to encounter situations where we have to load XMIResource's whose source
>>>>>file would be 10's or even 100's of megabytes.
>>>>>
>>>>>I have an idea I thought I would just give out to see if it is practical
>>>>>for the next EMF release. I know that whenever an inter-resource
>>>>>bi-directional reference is made through a non-containment feature, the
>>>>>two ends get serialized as proxies (at least with the XMIResource).
>>>>>Whenever each of the models is loaded by XMIResource, the proxies are left
>>>>>in memory until they are resolved. The resolution could force the loading
>>>>>of the other resource using the URI stored in the proxy. If the reference
>>>>>is bi-directional then either resource could load the other if either of
>>>>>the two proxies is being resolved.
>>>>>
>>>>>Couldn't something similar be used in containment features? Containment
>>>>>features are inherently bi-directional because the child knows about its
>>>>>parent by eContainer() and the parent knows about the child through the
>>>>>containment feature. That way the child could be placed into a separate
>>>>>resource and only loaded on-demand. This would allow anyone working with
>>>>>very large resources to split them up and only load portions of the
>>>>>resource when necessary.
>>>>>
>>>>>Just a thought,
>>>>>
>>>>>Chris McGee
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>
>
>
>
--------------090303030204090709060807
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Chris,<br>
<br>
Containment is supported to manage object lifetime.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 26 12:22:25 GMT 2024
Powered by FUDForum. Page generated in 0.03376 seconds |
] 
Search
Help
Register
Login
Home
