Home » Modeling » EMF » Soft Containment
|
| Re: Soft Containment [message #424572 is a reply to message #424565] |
Thu, 30 October 2008 10:47   |
 Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Andrew,
Your subject line scares me. Comments below.
Andrew H wrote:
> We have model with a set of products. There are many sub types of
> Product, each of which are typically a pretty large, complex graph of
> objects.
>
> The product tree tends to be made up largely of containment
> relationships and this fits well in most cases. However, sometimes we
> need to set up a set of related products where each product shares
> most of its features with other products.
>
> In a simple java bean model this is no problem. You can just do
> something like
>
> Product p1, p2;
> p1.setFeatureA(p2.getFeatureA());
>
> i.e. you simply poke in the same object for all the common bits. This
> works well and business rules tend to work the same regardless of
> whether its one product or 100 related ones.
Yes, but try to serialize it to XML and what happens? :-P
>
> Of course this doesn't work with containment as the above assignment
> will unplug this featureA from p2.
>
> Turning off containment would be very unattractive as it would mean we
> would need to be adding all the product features separately into a
> resource. Given the size of these models this would be hideous and
> complex.
Alternatively they need to be contained by some other containment reference.
>
> It would also make it very ugly in XML as the XML would look more like
> the java heap than a normal XML document.
I was hint at this earlier, consider carefully what you'd expect the
XML to look like...
>
> We could come up with separate models that were just models of the
> bits that were not shared, but in theory everything can be shared and
> we'd likely need new rules for these even though its really the same
> stuff we already modeled.
>
> We could do something like having two references for everything, one
> containment and one not. e.g.
> A featureA; // this one is not containment
> A featureADontLookAtMe; // this one is containment
Yes, that's an alternative...
>
> then featureA would either point to its own featureADontLookAtMe or
> another products one.
Like an "effectiveFeatureA" and an "ownedFeatureA"...
>
> For a couple of cases this may be feasible but not across the whole
> model.
Of course it's feasible no matter what, but just a lot more work.
>
> I think what I'm after is some concept of soft containment that would
> behave something like:
>
> - when a reference is set, if there is already a container for the
> object then just point to it.
> - Otherwise set this object as the container.
You could implement that kind of behavior in the setEffectiveFeatureA
method, i.e., also call setOwnedFeatureA.
>
> I would think we could probably make that work by customising the JET
> templates.
Other issues to consider. What happens if you delete the product that
owns the feature and then suddenly the other referencing products have
dangling references.
>
> We'd need to do something with the generated XSD too though.
As I was alluding earlier. The choice of owner determines where the
thing is physically nested and the lifetime is also controlled by that.
> We'd really need every reference to be a choice between a href and an
> element of the same type.
Just as if you modeled it that way in the first place...
> Would be a very ugly XSD I admit.
It must reflect how you serialize so given the choice of sharing you're
making, that's what it it implies.
>
> Has anyone else tackled this problem?
Mostly you have to decide who owns these things. If the feature has
life independent from a given product, then they probably ought not to
be contained/owned by a product. Likely they should be owned and
maintained by something else.
>
> Any thoughts on how to handle this?
Here's another alternative that comes to mind based on the semantics
you've described. It still involves having an effectiveFeatureA and a
featureA, but effectiveFeatureA would just be a transient derived
volatile reference because you'd have a relatedProduct feature that
points at another related product. The effectiveFeatureA would return
either the value of featureA, or would call effectiveFeatureA on the
relatedProduct. I.e., you'd inherit all the features of the related
product. You could just make effectiveFeatureA an EOperation I
suppose, but you get the idea. This seems to me a better way to model
the relatedness of products since the sharing otherwise might share
features simply because it seemed more convenient then copying, but of
course if the original feature changes, you affect things that maybe
should not be affected.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Soft Containment [message #424610 is a reply to message #424572] |
Fri, 31 October 2008 00:08 |
Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Hi Ed
Ed Merks wrote:
> Andrew,
> Your subject line scares me. Comments below.
I thought it was rather catchy myself :-)
> Andrew H wrote:
>> We have model with a set of products. There are many sub types of
>> Product, each of which are typically a pretty large, complex graph of
>> objects.
>>
>> The product tree tends to be made up largely of containment
>> relationships and this fits well in most cases. However, sometimes we
>> need to set up a set of related products where each product shares
>> most of its features with other products.
>>
>> In a simple java bean model this is no problem. You can just do
>> something like
>>
>> Product p1, p2;
>> p1.setFeatureA(p2.getFeatureA());
>>
>> i.e. you simply poke in the same object for all the common bits. This
>> works well and business rules tend to work the same regardless of
>> whether its one product or 100 related ones.
> Yes, but try to serialize it to XML and what happens? :-P
Yeah this is the main thing I've been struggling with. It's really a clash
of two worlds. The XML world which is completely obsessed with containment
and makes a big distinction between containment and non containment and a
Java world where there is not an inbuilt concept of containment.
Nobody considers what the structure of the Java heap looks like but
everyone thinks about the XML structure.
Of course in the database world containment is rather useful again so I am
certainly not an enemy of containment but I have a rather tricky problem
to solve that would be a non issue if I didn't have to consider
containment.
>>
>> Of course this doesn't work with containment as the above assignment
>> will unplug this featureA from p2.
>>
>> Turning off containment would be very unattractive as it would mean we
>> would need to be adding all the product features separately into a
>> resource. Given the size of these models this would be hideous and
>> complex.
> Alternatively they need to be contained by some other containment reference.
Unfortunately, there is no other logical owner of these things outside the
products themselves.
>>
>> It would also make it very ugly in XML as the XML would look more like
>> the java heap than a normal XML document.
> I was hint at this earlier, consider carefully what you'd expect the
> XML to look like...
My thinking was that you'd have like a master product (just the first one)
that would own everything and then the others that would refer to the
first. Our application would need to control the setup to ensure this.
i.e. something like
<fancyProduct>
<featureA id="f1">Feature details here</featureA>
<someUniqueFeatue>Something not shared</someUniqueFeatue>
</fancyProduct>
<fancyProduct>
<featureA href="f1"/>
<someUniqueFeatue>My own different feature</someUniqueFeatue>
</fancyProduct>
>>
>> We could come up with separate models that were just models of the
>> bits that were not shared, but in theory everything can be shared and
>> we'd likely need new rules for these even though its really the same
>> stuff we already modeled.
>>
>> We could do something like having two references for everything, one
>> containment and one not. e.g.
>> A featureA; // this one is not containment
>> A featureADontLookAtMe; // this one is containment
> Yes, that's an alternative...
>>
>> then featureA would either point to its own featureADontLookAtMe or
>> another products one.
> Like an "effectiveFeatureA" and an "ownedFeatureA"...
>>
>> For a couple of cases this may be feasible but not across the whole
>> model.
> Of course it's feasible no matter what, but just a lot more work.
>>
>> I think what I'm after is some concept of soft containment that would
>> behave something like:
>>
>> - when a reference is set, if there is already a container for the
>> object then just point to it.
>> - Otherwise set this object as the container.
> You could implement that kind of behavior in the setEffectiveFeatureA
> method, i.e., also call setOwnedFeatureA.
Yes I was thinking something similar. The problem is that there could be
hundreds (possibly even thousands) of features that are potentially
sharable. Manually creating two features for each of these would be a big
task.
Also I don't want anyone directly calling setOwnedFeatureA. Ideally I'd
like the feature to be invisible. Otherwise it severely pollutes the model
and doubles its size.
>>
>> I would think we could probably make that work by customising the JET
>> templates.
> Other issues to consider. What happens if you delete the product that
> owns the feature and then suddenly the other referencing products have
> dangling references.
Good point. We'd need to have our application control that or else do
something like randomly assign the next reference to it as the container.
That might be tricky though as we may not have a handle on these
references.
>>
>> We'd need to do something with the generated XSD too though.
> As I was alluding earlier. The choice of owner determines where the
> thing is physically nested and the lifetime is also controlled by that.
>> We'd really need every reference to be a choice between a href and an
>> element of the same type.
> Just as if you modeled it that way in the first place...
>> Would be a very ugly XSD I admit.
> It must reflect how you serialize so given the choice of sharing you're
> making, that's what it it implies.
Agreed. We'll just have to live with an ugly XSD.
>>
>> Has anyone else tackled this problem?
> Mostly you have to decide who owns these things. If the feature has
> life independent from a given product, then they probably ought not to
> be contained/owned by a product. Likely they should be owned and
> maintained by something else.
Its kind of blurred here. The same product definition can be used to set
up just a single product. In this case it is natural for the product to
own everything. As there are many different products (>30) and each
product is a large complex structure, changing this structure to non
containment references and then introducing some new structure to own the
features would highly undesirable.
>>
>> Any thoughts on how to handle this?
> Here's another alternative that comes to mind based on the semantics
> you've described. It still involves having an effectiveFeatureA and a
> featureA, but effectiveFeatureA would just be a transient derived
> volatile reference because you'd have a relatedProduct feature that
> points at another related product. The effectiveFeatureA would return
> either the value of featureA, or would call effectiveFeatureA on the
> relatedProduct. I.e., you'd inherit all the features of the related
> product. You could just make effectiveFeatureA an EOperation I
> suppose, but you get the idea. This seems to me a better way to model
> the relatedness of products since the sharing otherwise might share
> features simply because it seemed more convenient then copying, but of
> course if the original feature changes, you affect things that maybe
> should not be affected.
That's an interesting idea. How would that serialise to XML?
I've just found out the our trickiest case (i.e. the hundreds of related
products) will be imported from spreadsheets. This means they will come
into our system as completely separate products anyway so we'll have to
accept that they will have copies of stuff. This is actually a relief
cause we don't have a choice. It will hurt on performance though.
There are still several other cases but they involve smaller sets of
products. I'll do more analysis on these soon. It may be that we get away
with a combination of either copying and keeping features synchronised
with business rules, or using the manual double feature trick.
We plan to use OCL for some of these sorts of business rules and then
interpret the OCL to automatically synchronise features. e.g.
we hope to analyse an OCL expression like
product1.featureA = product2.featureA
and then depending on the context we either just validate this
relationship (i.e. standard behaviour from the EMF validation framework I
believe) or we actually trigger off setFeatureA and automatically set
featureA of the other product. This could potentially work in both
directions.
|
|
|
| Re: Soft Containment [message #424612 is a reply to message #424610] |
Fri, 31 October 2008 09:58 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Andrew,
Comments below.
Andrew H wrote:
> Hi Ed
>
> Ed Merks wrote:
>
>> Andrew,
>
>> Your subject line scares me. Comments below.
>
> I thought it was rather catchy myself :-)
It made me think back to a discussions I've had about weak containment.
Sometimes containment really bothers people. Of course those same
people don't seem to realize that DOM has the same concept and don't
seem bothered by it there, though I guess the point is they didn't
notice it was there.
>
>> Andrew H wrote:
>>> We have model with a set of products. There are many sub types of
>>> Product, each of which are typically a pretty large, complex graph
>>> of objects.
>>>
>>> The product tree tends to be made up largely of containment
>>> relationships and this fits well in most cases. However, sometimes
>>> we need to set up a set of related products where each product
>>> shares most of its features with other products.
>>>
>>> In a simple java bean model this is no problem. You can just do
>>> something like
>>>
>>> Product p1, p2;
>>> p1.setFeatureA(p2.getFeatureA());
>>>
>>> i.e. you simply poke in the same object for all the common bits.
>>> This works well and business rules tend to work the same regardless
>>> of whether its one product or 100 related ones.
>> Yes, but try to serialize it to XML and what happens? :-P
>
> Yeah this is the main thing I've been struggling with. It's really a
> clash of two worlds. The XML world which is completely obsessed with
> containment
It supports IDREF, i.e., untyped same document pointers, there are also
keyrefs, if you can figure out how they work, and I suppose via xpointer
or anyURI it supports cross document pointers, though not something XML
Schema or any other tool tends to support all that well.
> and makes a big distinction between containment and non containment
> and a Java world where there is not an inbuilt concept of containment.
Yes, in XML there is mostly just containment and in Java there is mostly
just non-containment.
Things like JAXB try to bridge them, but in my opinion, do a pretty poor
job. For example, they let you create a graph when only a tree is
valid. They don't manage containment at all, so to keep your structures
well-formed (i.e., maintain referential integrity) , you're on your
own. JAXB is perfectly happy to let to containment references refer to
the same object and happily copies them when you save so that when you
deserialize, you don't have the same structure you serialized...
But it's a standard, and people love standards, even when they're poor.
E.g., see other thread about SDO...
>
> Nobody considers what the structure of the Java heap looks like but
> everyone thinks about the XML structure.
Indeed. That is until you need to serialize it in human readable way.
>
> Of course in the database world containment is rather useful again so
> I am certainly not an enemy of containment but I have a rather tricky
> problem to solve that would be a non issue if I didn't have to
> consider containment.
One way to not consider containment is simply not to have any
containment references. When you need to serialize, you could just
follow all the references to gather up all the reachable objects in the
"heap" and you could dump those all at the root of the resource and
happily reflect the Java non-containment view of the world... It's
simple reflective code that could be written in just a few lines...
>
>>>
>>> Of course this doesn't work with containment as the above assignment
>>> will unplug this featureA from p2.
>>>
>>> Turning off containment would be very unattractive as it would mean
>>> we would need to be adding all the product features separately into
>>> a resource. Given the size of these models this would be hideous and
>>> complex.
>> Alternatively they need to be contained by some other containment
>> reference.
>
> Unfortunately, there is no other logical owner of these things outside
> the products themselves.
>
>
>>>
>>> It would also make it very ugly in XML as the XML would look more
>>> like the java heap than a normal XML document.
>> I was hint at this earlier, consider carefully what you'd expect the
>> XML to look like...
>
> My thinking was that you'd have like a master product (just the first
> one) that would own everything and then the others that would refer to
> the first. Our application would need to control the setup to ensure
> this.
Yep.
>
> i.e. something like
>
> <fancyProduct>
> <featureA id="f1">Feature details here</featureA>
> <someUniqueFeatue>Something not shared</someUniqueFeatue>
> </fancyProduct>
>
> <fancyProduct>
> <featureA href="f1"/>
> <someUniqueFeatue>My own different feature</someUniqueFeatue>
> </fancyProduct>
>
>>>
>>> We could come up with separate models that were just models of the
>>> bits that were not shared, but in theory everything can be shared
>>> and we'd likely need new rules for these even though its really the
>>> same stuff we already modeled.
>>>
>>> We could do something like having two references for everything, one
>>> containment and one not. e.g.
>>> A featureA; // this one is not containment
>>> A featureADontLookAtMe; // this one is containment
>> Yes, that's an alternative...
>>>
>>> then featureA would either point to its own featureADontLookAtMe or
>>> another products one.
>> Like an "effectiveFeatureA" and an "ownedFeatureA"...
>>>
>>> For a couple of cases this may be feasible but not across the whole
>>> model.
>> Of course it's feasible no matter what, but just a lot more work.
>>>
>>> I think what I'm after is some concept of soft containment that
>>> would behave something like:
>>>
>>> - when a reference is set, if there is already a container for the
>>> object then just point to it.
>>> - Otherwise set this object as the container.
>> You could implement that kind of behavior in the setEffectiveFeatureA
>> method, i.e., also call setOwnedFeatureA.
>
> Yes I was thinking something similar. The problem is that there could
> be hundreds (possibly even thousands) of features that are potentially
> sharable. Manually creating two features for each of these would be a
> big task.
Again, reflection is your best friend. You could imagine writing a
utility that given an Ecore model as input, that would produce a
transformed one as output... In combination with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701 that could work
quite well, or you could produce EOperations with body annotations.
>
> Also I don't want anyone directly calling setOwnedFeatureA. Ideally
> I'd like the feature to be invisible.
Someone needs to decide who owns it, unless it's just luck of the draw
for the first.
> Otherwise it severely pollutes the model and doubles its size.
Features can be annotated to suppress their accessors from the API, so
this is easy to control.
>
>>>
>>> I would think we could probably make that work by customising the
>>> JET templates.
>> Other issues to consider. What happens if you delete the product
>> that owns the feature and then suddenly the other referencing
>> products have dangling references.
>
> Good point. We'd need to have our application control that or else do
> something like randomly assign the next reference to it as the
> container. That might be tricky though as we may not have a handle on
> these references.
Yes, tricky.
>
>>>
>>> We'd need to do something with the generated XSD too though.
>> As I was alluding earlier. The choice of owner determines where the
>> thing is physically nested and the lifetime is also controlled by that.
>>> We'd really need every reference to be a choice between a href and
>>> an element of the same type.
>> Just as if you modeled it that way in the first place...
>>> Would be a very ugly XSD I admit.
>> It must reflect how you serialize so given the choice of sharing
>> you're making, that's what it it implies.
>
> Agreed. We'll just have to live with an ugly XSD.
They're ugly anyway.
>
>>>
>>> Has anyone else tackled this problem?
>> Mostly you have to decide who owns these things. If the feature has
>> life independent from a given product, then they probably ought not
>> to be contained/owned by a product. Likely they should be owned and
>> maintained by something else.
>
> Its kind of blurred here. The same product definition can be used to
> set up just a single product. In this case it is natural for the
> product to own everything. As there are many different products (>30)
> and each product is a large complex structure, changing this structure
> to non containment references and then introducing some new structure
> to own the features would highly undesirable.
Yes, kind of some action at a distance kind of thing...
>
>
>>>
>>> Any thoughts on how to handle this?
>> Here's another alternative that comes to mind based on the semantics
>> you've described. It still involves having an effectiveFeatureA and
>> a featureA, but effectiveFeatureA would just be a transient derived
>> volatile reference because you'd have a relatedProduct feature that
>> points at another related product. The effectiveFeatureA would
>> return either the value of featureA, or would call effectiveFeatureA
>> on the relatedProduct. I.e., you'd inherit all the features of the
>> related product. You could just make effectiveFeatureA an
>> EOperation I suppose, but you get the idea. This seems to me a
>> better way to model the relatedness of products since the sharing
>> otherwise might share features simply because it seemed more
>> convenient then copying, but of course if the original feature
>> changes, you affect things that maybe should not be affected.
>
> That's an interesting idea. How would that serialise to XML?
You'd have an href to the relatedProduct (parentProduct) and the
features would all be optional such that the effectiveFeatureA would
return the local value, or call getEffectiveFeatureA on the related or
parent product.
>
> I've just found out the our trickiest case (i.e. the hundreds of
> related products) will be imported from spreadsheets.
Which will give no indication of how features are shared...
> This means they will come into our system as completely separate
> products anyway so we'll have to accept that they will have copies of
> stuff. This is actually a relief cause we don't have a choice. It will
> hurt on performance though.
Best to measure performance before assuming it will be an issue.
>
> There are still several other cases but they involve smaller sets of
> products. I'll do more analysis on these soon. It may be that we get
> away with a combination of either copying and keeping features
> synchronised with business rules, or using the manual double feature
> trick.
>
> We plan to use OCL for some of these sorts of business rules and then
> interpret the OCL to automatically synchronise features. e.g.
>
> we hope to analyse an OCL expression like
>
> product1.featureA = product2.featureA
I see.
>
> and then depending on the context we either just validate this
> relationship (i.e. standard behaviour from the EMF validation
> framework I believe) or we actually trigger off setFeatureA and
> automatically set featureA of the other product. This could
> potentially work in both directions.
Good luck.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Soft Containment [message #424696 is a reply to message #424612] |
Mon, 03 November 2008 03:04 |
Andrew H
Messages: 117
Registered: July 2009 |
Senior Member |
|
|
Ed Merks wrote:
> Andrew,
> Comments below.
> Andrew H wrote:
>> Hi Ed
>>
>> Ed Merks wrote:
>>
>>> Andrew,
>>
>>> Your subject line scares me. Comments below.
>>
>> I thought it was rather catchy myself :-)
> It made me think back to a discussions I've had about weak containment.
> Sometimes containment really bothers people. Of course those same
> people don't seem to realize that DOM has the same concept and don't
> seem bothered by it there, though I guess the point is they didn't
> notice it was there.
Yeah Weak Containment would probably have been a better subject.
Most of the time I find containment annoying. However, XML kind of has
forced it on us so I agree that it makes sense to have meta model that
explicitly models it.
You either need to live with the restrictions that containment puts on you
or you need to accept that you'll have fairly unreadable XML.
>>
>>
>> Yeah this is the main thing I've been struggling with. It's really a
>> clash of two worlds. The XML world which is completely obsessed with
>> containment
> It supports IDREF, i.e., untyped same document pointers, there are also
> keyrefs, if you can figure out how they work, and I suppose via xpointer
> or anyURI it supports cross document pointers, though not something XML
> Schema or any other tool tends to support all that well.
>> and makes a big distinction between containment and non containment
>> and a Java world where there is not an inbuilt concept of containment.
> Yes, in XML there is mostly just containment and in Java there is mostly
> just non-containment.
> Things like JAXB try to bridge them, but in my opinion, do a pretty poor
> job. For example, they let you create a graph when only a tree is
> valid. They don't manage containment at all, so to keep your structures
> well-formed (i.e., maintain referential integrity) , you're on your
> own. JAXB is perfectly happy to let to containment references refer to
> the same object and happily copies them when you save so that when you
> deserialize, you don't have the same structure you serialized...
> But it's a standard, and people love standards, even when they're poor.
> E.g., see other thread about SDO...
Its a tricky problem. If I didn't have to deal with XML then I'd probably
want much less containment because of the flexibility it gives you in
sharing things.
However, its not just XML that containment becomes useful. In Teneo, the
containment references is a useful way to control fetching. This feature
saved me from needing to do quite a lot of eager fetch code or
alternatively lots of hibernate mapping customisations.
Which is why I posted this in the first place. How do you work with
containment and minimise the issues it creates?
>>
>> Nobody considers what the structure of the Java heap looks like but
>> everyone thinks about the XML structure.
> Indeed. That is until you need to serialize it in human readable way.
Yes I often wish it wasn't human readable. Then we wouldn't care so much
about how it looks.
>>
>> Of course in the database world containment is rather useful again so
>> I am certainly not an enemy of containment but I have a rather tricky
>> problem to solve that would be a non issue if I didn't have to
>> consider containment.
> One way to not consider containment is simply not to have any
> containment references. When you need to serialize, you could just
> follow all the references to gather up all the reachable objects in the
> "heap" and you could dump those all at the root of the resource and
> happily reflect the Java non-containment view of the world... It's
> simple reflective code that could be written in just a few lines...
Interesting idea. That might be a very useful trick.
>> Yes I was thinking something similar. The problem is that there could
>> be hundreds (possibly even thousands) of features that are potentially
>> sharable. Manually creating two features for each of these would be a
>> big task.
> Again, reflection is your best friend. You could imagine writing a
> utility that given an Ecore model as input, that would produce a
> transformed one as output... In combination with
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701 that could work
> quite well, or you could produce EOperations with body annotations.
That's true. I had thought more on customising the Java Templates but
transforming the model into more of an 'implemention model' is another
idea.
>>
>> Also I don't want anyone directly calling setOwnedFeatureA. Ideally
>> I'd like the feature to be invisible.
> Someone needs to decide who owns it, unless it's just luck of the draw
> for the first.
I was planning on it being just luck of the draw, although the UI would
set it up so that it was created in a certain way. Outside the UI though I
guess it would be just luck again which would be fairly ugly I guess.
>> Otherwise it severely pollutes the model and doubles its size.
> Features can be annotated to suppress their accessors from the API, so
> this is easy to control.
Didn't know that. That would help make it less ugly.
>>
>> That's an interesting idea. How would that serialise to XML?
> You'd have an href to the relatedProduct (parentProduct) and the
> features would all be optional such that the effectiveFeatureA would
> return the local value, or call getEffectiveFeatureA on the related or
> parent product.
I like that idea. It means we don't need to specifically set up references
to all that's shared but instead just point at the top level. I might
explore that further when I get stuck into this.
>>
>> I've just found out the our trickiest case (i.e. the hundreds of
>> related products) will be imported from spreadsheets.
> Which will give no indication of how features are shared...
Exactly. It will all come in copied so the concept of sharing will be
irrelevant for these.
|
|
|
| Re: Soft Containment [message #424715 is a reply to message #424696] |
Mon, 03 November 2008 12:51 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Andrew,
Comments below.
Andrew H wrote:
> Ed Merks wrote:
>
>> Andrew,
>
>> Comments below.
>
>> Andrew H wrote:
>>> Hi Ed
>>>
>>> Ed Merks wrote:
>>>
>>>> Andrew,
>>>
>>>> Your subject line scares me. Comments below.
>>>
>>> I thought it was rather catchy myself :-)
>> It made me think back to a discussions I've had about weak
>> containment. Sometimes containment really bothers people. Of course
>> those same people don't seem to realize that DOM has the same concept
>> and don't seem bothered by it there, though I guess the point is they
>> didn't notice it was there.
>
> Yeah Weak Containment would probably have been a better subject.
Nooooo! :-P
>
> Most of the time I find containment annoying.
I suspect that phase will pass.
> However, XML kind of has forced it on us so I agree that it makes
> sense to have meta model that explicitly models it.
It's more than something forced by XML. It's a fundamental modeling
concept. It has to do with managing lifetime of instances. A contained
object will live only as long as its container... Even "folders nested
in folders" of the file system are modeled in this way; with links as
non-containment references. It's pervasive pattern...
>
> You either need to live with the restrictions that containment puts on
> you or you need to accept that you'll have fairly unreadable XML.
That's almost an oxymoron given that XML is at best fairly readable to
begin with and at worse is just so many long-winded brackets.
>
>>>
>>>
>>> Yeah this is the main thing I've been struggling with. It's really a
>>> clash of two worlds. The XML world which is completely obsessed with
>>> containment
>> It supports IDREF, i.e., untyped same document pointers, there are
>> also keyrefs, if you can figure out how they work, and I suppose via
>> xpointer or anyURI it supports cross document pointers, though not
>> something XML Schema or any other tool tends to support all that well.
>>> and makes a big distinction between containment and non containment
>>> and a Java world where there is not an inbuilt concept of containment.
>> Yes, in XML there is mostly just containment and in Java there is
>> mostly just non-containment.
>
>> Things like JAXB try to bridge them, but in my opinion, do a pretty
>> poor job. For example, they let you create a graph when only a tree
>> is valid. They don't manage containment at all, so to keep your
>> structures well-formed (i.e., maintain referential integrity) ,
>> you're on your own. JAXB is perfectly happy to let to containment
>> references refer to the same object and happily copies them when you
>> save so that when you deserialize, you don't have the same structure
>> you serialized...
>
>> But it's a standard, and people love standards, even when they're
>> poor. E.g., see other thread about SDO...
>
> Its a tricky problem. If I didn't have to deal with XML then I'd
> probably want much less containment because of the flexibility it
> gives you in sharing things.
You'd still need a way to keep track of who's doing the sharing or you'd
have features that aren't used in any product and no way to find
them... So likely then you'd end up with bidirectional references so
you'd know who's using each feature without having to index the known
universe.
> However, its not just XML that containment becomes useful. In Teneo,
> the containment references is a useful way to control fetching.
Databases too like to have things live in tables.
> This feature saved me from needing to do quite a lot of eager fetch
> code or alternatively lots of hibernate mapping customisations.
>
> Which is why I posted this in the first place. How do you work with
> containment and minimise the issues it creates?
Embrace the issues. Make them your friend. :-P
>
>>>
>>> Nobody considers what the structure of the Java heap looks like but
>>> everyone thinks about the XML structure.
>> Indeed. That is until you need to serialize it in human readable way.
>
> Yes I often wish it wasn't human readable. Then we wouldn't care so
> much about how it looks.
Except when we manage it in our minds...
>
>>>
>>> Of course in the database world containment is rather useful again
>>> so I am certainly not an enemy of containment but I have a rather
>>> tricky problem to solve that would be a non issue if I didn't have
>>> to consider containment.
>> One way to not consider containment is simply not to have any
>> containment references. When you need to serialize, you could just
>> follow all the references to gather up all the reachable objects in
>> the "heap" and you could dump those all at the root of the resource
>> and happily reflect the Java non-containment view of the world...
>> It's simple reflective code that could be written in just a few lines...
>
> Interesting idea. That might be a very useful trick.
>
>
>>> Yes I was thinking something similar. The problem is that there
>>> could be hundreds (possibly even thousands) of features that are
>>> potentially sharable. Manually creating two features for each of
>>> these would be a big task.
>> Again, reflection is your best friend. You could imagine writing a
>> utility that given an Ecore model as input, that would produce a
>> transformed one as output... In combination with
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701 that could work
>> quite well, or you could produce EOperations with body annotations.
>
> That's true. I had thought more on customising the Java Templates but
> transforming the model into more of an 'implemention model' is another
> idea.
>
>>>
>>> Also I don't want anyone directly calling setOwnedFeatureA. Ideally
>>> I'd like the feature to be invisible.
>> Someone needs to decide who owns it, unless it's just luck of the
>> draw for the first.
>
> I was planning on it being just luck of the draw, although the UI
> would set it up so that it was created in a certain way. Outside the
> UI though I guess it would be just luck again which would be fairly
> ugly I guess.
That sounds horrible. :-P
>
>>> Otherwise it severely pollutes the model and doubles its size.
>> Features can be annotated to suppress their accessors from the API,
>> so this is easy to control.
>
> Didn't know that. That would help make it less ugly.
>
>>>
>>> That's an interesting idea. How would that serialise to XML?
>> You'd have an href to the relatedProduct (parentProduct) and the
>> features would all be optional such that the effectiveFeatureA would
>> return the local value, or call getEffectiveFeatureA on the related
>> or parent product.
>
> I like that idea. It means we don't need to specifically set up
> references to all that's shared but instead just point at the top
> level. I might explore that further when I get stuck into this.
>
>>>
>>> I've just found out the our trickiest case (i.e. the hundreds of
>>> related products) will be imported from spreadsheets.
>> Which will give no indication of how features are shared...
>
> Exactly. It will all come in copied so the concept of sharing will be
> irrelevant for these.
It would seem worrisome if you can never be sure that a change you make
will only affect the one product or will be shared by who knows which
products...
>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 06:48:42 GMT 2024
Powered by FUDForum. Page generated in 0.02923 seconds |
] 
Search
Help
Register
Login
Home
