|
| Re: The RESTful EMF containment paradox [message #428222 is a reply to message #428216] |
Sat, 14 March 2009 11:28   |
 Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Bryan,
Comments below.
Bryan Hunt wrote:
> I'm starting to look into persisting EMF models using the RESTful web
> service APIs and I've run into an interesting paradox. Using the
> classic EMF example, consider a PurchaseOrder that references Item.
> The reference is naturally a containment reference - when you delete a
> PurchaseOrder, you need to delete all Items. The RESTful backing
> store is based on a resource-oriented architecture, and there is a
> use-case where the Items need to be stored in a separate resource
> (URI) from the PurchaseOrder. This physical storage of the model best
> mapps to a non-containment reference - thus, the paradox. (This is
> not the best example to illustrate the paradox - I wanted a familiar
> example.)
EMF supports cross resource containment as well though. See the answer
to the previous post. Of course XML Schema has no provision for such a
think, though xinclude is similar though it's a low level syntactic thing...
>
> My first attempt at a solution will be to model items as a
> non-containment reference, and use a domain specific storage service
> to delete the Items when the PurchaseOrder is deleted.
>
> Are there any other best practices for solving this paradox?
Even for Ecore itself, it's possible to put an classifier or a
subpackage in a separate resource. In a generated editor, you can use
Control... to accomplish this.
>
> Bryan
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: The RESTful EMF containment paradox [message #428229 is a reply to message #428222] |
Sun, 15 March 2009 04:14 |
Bryan Hunt
Messages: 366
Registered: July 2009 |
Senior Member |
|
|
Thanks Ed! I've learned something new and useful :)
Bryan
On 2009-03-14 06:28:53 -0500, Ed Merks <Ed.Merks@gmail.com> said:
> Bryan,
>
> Comments below.
>
> Bryan Hunt wrote:
>> I'm starting to look into persisting EMF models using the RESTful web
>> service APIs and I've run into an interesting paradox. Using the
>> classic EMF example, consider a PurchaseOrder that references Item.
>> The reference is naturally a containment reference - when you delete a
>> PurchaseOrder, you need to delete all Items. The RESTful backing store
>> is based on a resource-oriented architecture, and there is a use-case
>> where the Items need to be stored in a separate resource (URI) from the
>> PurchaseOrder. This physical storage of the model best mapps to a
>> non-containment reference - thus, the paradox. (This is not the best
>> example to illustrate the paradox - I wanted a familiar example.)
> EMF supports cross resource containment as well though. See the answer
> to the previous post. Of course XML Schema has no provision for such a
> think, though xinclude is similar though it's a low level syntactic
> thing...
>>
>> My first attempt at a solution will be to model items as a
>> non-containment reference, and use a domain specific storage service to
>> delete the Items when the PurchaseOrder is deleted.
>>
>> Are there any other best practices for solving this paradox?
> Even for Ecore itself, it's possible to put an classifier or a
> subpackage in a separate resource. In a generated editor, you can use
> Control... to accomplish this.
>>
>> Bryan
|
|
|
| Re: The RESTful EMF containment paradox [message #512125 is a reply to message #428222] |
Thu, 04 February 2010 03:20 |
Ben
Messages: 5
Registered: January 2010 |
Junior Member |
|
|
Hi Ed,
I have a follow up question on your response below.
Ed Merks wrote:
> Bryan,
>
> Comments below.
>
> Bryan Hunt wrote:
>> I'm starting to look into persisting EMF models using the RESTful web
>> service APIs and I've run into an interesting paradox. Using the
>> classic EMF example, consider a PurchaseOrder that references Item.
>> The reference is naturally a containment reference - when you delete a
>> PurchaseOrder, you need to delete all Items. The RESTful backing
>> store is based on a resource-oriented architecture, and there is a
>> use-case where the Items need to be stored in a separate resource
>> (URI) from the PurchaseOrder. This physical storage of the model best
>> mapps to a non-containment reference - thus, the paradox. (This is
>> not the best example to illustrate the paradox - I wanted a familiar
>> example.)
> EMF supports cross resource containment as well though. See the answer
> to the previous post. Of course XML Schema has no provision for such a
> think, though xinclude is similar though it's a low level syntactic thing...n
Is there a good solution/pattern to use cross-resource containment for XML resources given a certain resolution algorithm?
In the REST example above, I may know that items for a given purchase order are always located in a specific sub directory.
One thing I ran into when I was trying to use cross-resource containment with XML resources is that the child EObjects get detached from their resource when adding them to the parent, since their initial parent is the model-specific DocumentRoot (as opposed to the resource in the XMI case).
>>
>> My first attempt at a solution will be to model items as a
>> non-containment reference, and use a domain specific storage service
>> to delete the Items when the PurchaseOrder is deleted.
>>
>> Are there any other best practices for solving this paradox?
> Even for Ecore itself, it's possible to put an classifier or a
> subpackage in a separate resource. In a generated editor, you can use
> Control... to accomplish this.
>>
>> Bryan
|
|
|
| Re: The RESTful EMF containment paradox [message #512195 is a reply to message #512125] |
Thu, 04 February 2010 11:21 |
Ed Merks
Messages: 33142
Registered: July 2009 |
Senior Member |
|
|
Ben,
Comments below.
Ben wrote:
> Hi Ed,
>
> I have a follow up question on your response below.
>
> Ed Merks wrote:
>
>> Bryan,
>>
>> Comments below.
>>
>> Bryan Hunt wrote:
>>> I'm starting to look into persisting EMF models using the RESTful web
>>> service APIs and I've run into an interesting paradox. Using the
>>> classic EMF example, consider a PurchaseOrder that references Item.
>>> The reference is naturally a containment reference - when you delete a
>>> PurchaseOrder, you need to delete all Items. The RESTful backing
>>> store is based on a resource-oriented architecture, and there is a
>>> use-case where the Items need to be stored in a separate resource
>>> (URI) from the PurchaseOrder. This physical storage of the model best
>>> mapps to a non-containment reference - thus, the paradox. (This is
>>> not the best example to illustrate the paradox - I wanted a familiar
>>> example.)
>> EMF supports cross resource containment as well though. See the answer
>> to the previous post. Of course XML Schema has no provision for such a
>> think, though xinclude is similar though it's a low level syntactic
>> thing...n
>
> Is there a good solution/pattern to use cross-resource containment for
> XML resources given a certain resolution algorithm?
>
> In the REST example above, I may know that items for a given purchase
> order are always located in a specific sub directory.
That doesn't sound very RESTful though.
>
> One thing I ran into when I was trying to use cross-resource
> containment with XML resources is that the child EObjects get detached
> from their resource when adding them to the parent, since their
> initial parent is the model-specific DocumentRoot (as opposed to the
> resource in the XMI case).
That's true. I suppose one would need to make use of
OPTION_SUPPRESS_DOCUMENT_ROOT.
>
>>>
>>> My first attempt at a solution will be to model items as a
>>> non-containment reference, and use a domain specific storage service
>>> to delete the Items when the PurchaseOrder is deleted.
>>>
>>> Are there any other best practices for solving this paradox?
>> Even for Ecore itself, it's possible to put an classifier or a
>> subpackage in a separate resource. In a generated editor, you can use
>> Control... to accomplish this.
>>>
>>> Bryan
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03574 seconds
] 
Search
Help
Register
Login
Home
