Home » Modeling » EMF » How should I model this relationship.
| |
| Re: How should I model this relationship. [message #1008279 is a reply to message #1005954] |
Mon, 11 February 2013 12:47   |
 Roland Tepp
Messages: 36
Registered: July 2009 |
Member |
|
|
Hey Ed,
I would rather not do that as the backend storage (DB schema) of the
model is not very likely to change any time soon and I have very little
influence to change that.
I remember a discussion from a way back about using derived feature to
find all references pointing at the EObject, but I can't find this any
more...
As a more general question - what is the preferred solution to model
this type of references in EMF - specially considering that I might want
to be able change the actual Resource implementation depending on the
deployment scenario at some point in future?
29.01.2013 14:00, Ed Merks kirjutas:
> Roland,
>
> You could model it as a bidirectional non-containment reference like this:
>
> package org.example.order
>
> class Order
> {
> refers Order previous opposite next
> refers Order[] next opposite previous
> }
>
> Of course this implies that adding a order will require saving the the
> previous order to update the back reference; not sure if that's okay in
> your design. The GenFeature for next can be configured to be displayed
> as children in a tree view.
>
>
> On 29/01/2013 11:40 AM, Roland Tepp wrote:
>> Hey,
>>
>> I am trying to create an EMF model for a legacy system as a PoC and I
>> am currently torn in how to model the relationship below.
>>
>> Being a relative newbie in modelling, I need some advice and pointers.
>>
>> The system I am trying to model is a provisioning orders subsystem.
>>
>> The main object in this system is an Order.
>> Each order may have a reference to a "previous" order that establishes
>> order of execution of these Orders - the one that has a "previous"
>> reference would not be executed before the one it referes to..
>>
>> So for example I would have following set of orders (where "<-" refers
>> to a previous order):
>>
>> O1 <- O2 <- O3
>> O2 <- O4 <- O5
>>
>> Another way of visualizing this relationship is by using a tree-like
>> representation:
>>
>> O1 <- O2 <- O3
>> ^
>> |
>> O4 <- O5
>>
>>
>> The reverese relationship is a lot like a containment relationshp, but
>> the orders are their own entities, so I can not really model them as
>> contained within other Orders.
>>
>> On the other hand I need to be able to browse the reverse of
>> "previous" reference. I seem to remember an article describing this
>> type of a feature, but I can't find anything about it...
>
|
|
|
| Re: How should I model this relationship. [message #1008343 is a reply to message #1008279] |
Tue, 12 February 2013 05:19 |
Ed Merks
Messages: 33147
Registered: July 2009 |
Senior Member |
|
|
Roland,
Comments below.
On 11/02/2013 1:47 PM, Roland Tepp wrote:
> Hey Ed,
>
> I would rather not do that as the backend storage (DB schema) of the
> model is not very likely to change any time soon and I have very
> little influence to change that.
In terms of back end storage, it's not necessary that you persist both
ends of the reference. You could populate "next" from a database query.
>
> I remember a discussion from a way back about using derived feature to
> find all references pointing at the EObject, but I can't find this any
> more...
Something like an ECrossReferenceAdapter can be used to manage inverse
relationships, but it relies on all objects of interest being in the
resource set.
>
> As a more general question - what is the preferred solution to model
> this type of references in EMF - specially considering that I might
> want to be able change the actual Resource implementation depending on
> the deployment scenario at some point in future?
Logically what you describe is modeled as I've shown. How that's
persisted to storage is another question but I don't know how you're
currently managing that. Certainly if everything is in a data base, the
problem is somewhat simpler because if the order of "next" doesn't
matter (you can mark it "unordered"), you can populate it from a query...
>
>
> 29.01.2013 14:00, Ed Merks kirjutas:
>> Roland,
>>
>> You could model it as a bidirectional non-containment reference like
>> this:
>>
>> package org.example.order
>>
>> class Order
>> {
>> refers Order previous opposite next
>> refers Order[] next opposite previous
>> }
>>
>> Of course this implies that adding a order will require saving the the
>> previous order to update the back reference; not sure if that's okay in
>> your design. The GenFeature for next can be configured to be displayed
>> as children in a tree view.
>>
>>
>> On 29/01/2013 11:40 AM, Roland Tepp wrote:
>>> Hey,
>>>
>>> I am trying to create an EMF model for a legacy system as a PoC and I
>>> am currently torn in how to model the relationship below.
>>>
>>> Being a relative newbie in modelling, I need some advice and pointers.
>>>
>>> The system I am trying to model is a provisioning orders subsystem.
>>>
>>> The main object in this system is an Order.
>>> Each order may have a reference to a "previous" order that establishes
>>> order of execution of these Orders - the one that has a "previous"
>>> reference would not be executed before the one it referes to..
>>>
>>> So for example I would have following set of orders (where "<-" refers
>>> to a previous order):
>>>
>>> O1 <- O2 <- O3
>>> O2 <- O4 <- O5
>>>
>>> Another way of visualizing this relationship is by using a tree-like
>>> representation:
>>>
>>> O1 <- O2 <- O3
>>> ^
>>> |
>>> O4 <- O5
>>>
>>>
>>> The reverese relationship is a lot like a containment relationshp, but
>>> the orders are their own entities, so I can not really model them as
>>> contained within other Orders.
>>>
>>> On the other hand I need to be able to browse the reverse of
>>> "previous" reference. I seem to remember an article describing this
>>> type of a feature, but I can't find anything about it...
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: How should I model this relationship. [message #1010913 is a reply to message #1008343] |
Mon, 18 February 2013 13:24 |
Roland Tepp
Messages: 36
Registered: July 2009 |
Member |
|
|
Hi Ed,
Replies below.
12.02.2013 7:19, Ed Merks kirjutas:
> Roland,
>
> Comments below.
>
> On 11/02/2013 1:47 PM, Roland Tepp wrote:
>> Hey Ed,
>>
>> I would rather not do that as the backend storage (DB schema) of the
>> model is not very likely to change any time soon and I have very
>> little influence to change that.
> In terms of back end storage, it's not necessary that you persist both
> ends of the reference. You could populate "next" from a database query.
>>
Yes, this is certainly a workable option.
However I would not want to be eagerly populating this list at load
time. Is there a way to have the whole list of "children" be proxied
without needing to know their ids up front.
(on the other hand, these clusters of related Order objects are fairly
small and well-contained, so this might not be as big of a overhead as I
am imagining it)
>> I remember a discussion from a way back about using derived feature to
>> find all references pointing at the EObject, but I can't find this any
>> more...
> Something like an ECrossReferenceAdapter can be used to manage inverse
> relationships, but it relies on all objects of interest being in the
> resource set.
>>
Ah, that is somewhat undesireable - I really do not want to load the
entire world at startup...
>> As a more general question - what is the preferred solution to model
>> this type of references in EMF - specially considering that I might
>> want to be able change the actual Resource implementation depending on
>> the deployment scenario at some point in future?
> Logically what you describe is modeled as I've shown. How that's
> persisted to storage is another question but I don't know how you're
> currently managing that. Certainly if everything is in a data base, the
> problem is somewhat simpler because if the order of "next" doesn't
> matter (you can mark it "unordered"), you can populate it from a query...
yes, that is certainly a possibility.
|
|
|
| Re: How should I model this relationship. [message #1011024 is a reply to message #1010913] |
Mon, 18 February 2013 17:25 |
Ed Merks
Messages: 33147
Registered: July 2009 |
Senior Member |
|
|
Roland,
Comments below.
On 18/02/2013 2:24 PM, Roland Tepp wrote:
> Hi Ed,
>
> Replies below.
>
> 12.02.2013 7:19, Ed Merks kirjutas:
>> Roland,
>>
>> Comments below.
>>
>> On 11/02/2013 1:47 PM, Roland Tepp wrote:
>>> Hey Ed,
>>>
>>> I would rather not do that as the backend storage (DB schema) of the
>>> model is not very likely to change any time soon and I have very
>>> little influence to change that.
>> In terms of back end storage, it's not necessary that you persist both
>> ends of the reference. You could populate "next" from a database
>> query.
>>>
> Yes, this is certainly a workable option.
> However I would not want to be eagerly populating this list at load
> time. Is there a way to have the whole list of "children" be proxied
> without needing to know their ids up front.
No, a list itself can't be a proxy.
>
> (on the other hand, these clusters of related Order objects are fairly
> small and well-contained, so this might not be as big of a overhead as
> I am imagining it)
It always pays to measure first and worry later.
>
>
>>> I remember a discussion from a way back about using derived feature to
>>> find all references pointing at the EObject, but I can't find this any
>>> more...
>> Something like an ECrossReferenceAdapter can be used to manage inverse
>> relationships, but it relies on all objects of interest being in the
>> resource set.
>>>
> Ah, that is somewhat undesireable - I really do not want to load the
> entire world at startup...
Exactly.
>
>>> As a more general question - what is the preferred solution to model
>>> this type of references in EMF - specially considering that I might
>>> want to be able change the actual Resource implementation depending on
>>> the deployment scenario at some point in future?
>> Logically what you describe is modeled as I've shown. How that's
>> persisted to storage is another question but I don't know how you're
>> currently managing that. Certainly if everything is in a data base, the
>> problem is somewhat simpler because if the order of "next" doesn't
>> matter (you can mark it "unordered"), you can populate it from a
>> query...
> yes, that is certainly a possibility.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Wed May 15 02:23:41 GMT 2024
Powered by FUDForum. Page generated in 0.03310 seconds |
] 
Search
Help
Register
Login
Home
