|
| Re: determinism on QVTo execution [message #1589143 is a reply to message #1588942] |
Wed, 28 January 2015 09:04   |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
Any algorithm that uses a Set or a Map is very unlikely to be
determinate since the Java hashcodes can include address which is
indeterminate as soon as you allow multiple threads (e.g. garbage
collection) into your execution. allSubobjectsOfType(...) is defined to
return a Set(Element).
Assuming that subobject means contained object (not actually specified),
since UML only supports single containment, a Set is not needed to avoid
duplicates. However to provide a determinstic order would require the
specification to impose:
- an artificial order on unordered children
- a relative order of features - UML's Class::ownedAttribute is ordered,
but superClasses is not so an artificial inheritance ordering is needed
- a specified pre-order/post-order/breadth-first ordering of child objects.
The specification sensibly chooses not to impose such a constraint on
implementations.
With EMF you are sometimes spoiled because the storage for a {unique}
collection is a UniqueEList. However anything that creates a projection
will create a new Set and so be indeterminate.
If you want determinism you should start by sorting into a deterministic
order or traversing in a deterministic order.
You could raise a Bugzilla suggesting that QVTo, or more likely OCL, or
more flexibly EMF, provide an optional capability to allocate a stable
address-independent ID to all objects and to maintain all sets in a
stable order determined by that ID. This could impose significant
overheads so I don't see anyone rushing to implement it.
EMF: If the ID is based on EObject creation order, I think you will
struggle to achieve determinism without rewriting all model loaders to
enforce determinism. For instance, are you sure that the objects in a
model provided by CDO will be in identical order if you migrate to a
different backend repository? If the ID is instead based on deep
context, you will struggle to identify a consistent time to allocate the
stable ID given that EMF allows context to change.
OCL: Loaded models are not allowed to change, so IDs could be allocated
using deep context as a post-load algorithm. Then all Set algorithms
must be revised.
QVTo: Extending OCL policy, further IDs can probably be allocated
sequentially and all Set algorithms revised.
Nasty. A pain to write. Even more of a pain to test and maintain.
Regards
Ed Willink
On 28/01/2015 06:26, Thomas Busch wrote:
> Hi,
>
> I observed on execution of the same transformation, that from run to
> run (without ANY change in Eclipse) e.g. allSubobjectsOfType(...) does
> not process the Subobjects in the same order. Nearly every time they
> are used in a different sequence.
>
> Is there a trick to get QVTo to handle them every time in the same order?
>
> Is this behaviour really intentionally? I could think of tons of stuff
> where this can be very annoying, e.g. on debugging a faulty
> transformation, which only show its fault when it finds the wrong
> object first.
|
|
|
|
Powered by
FUDForum. Page generated in 0.02985 seconds
] 
Search
Help
Register
Login
Home
