Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-OML » determinism on QVTo execution
determinism on QVTo execution [message #1588942] Wed, 28 January 2015 06:26 Go to next message
Thomas Busch is currently offline Thomas BuschFriend
Messages: 23
Registered: November 2014
Junior Member
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.
Re: determinism on QVTo execution [message #1589143 is a reply to message #1588942] Wed, 28 January 2015 09:04 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5472
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.
Re: determinism on QVTo execution [message #1589258 is a reply to message #1589143] Wed, 28 January 2015 10:26 Go to previous message
Thomas Busch is currently offline Thomas BuschFriend
Messages: 23
Registered: November 2014
Junior Member
ok, I conclude the following for me:
- indeterminism is tolerated and too costly to remove
- my best practice will be to just add to all Collection where determinism is needed "->sortedBy(...)" before I process them (e.g. via forEach(...))

I tested that additional sorting and it worked fine.

Thank you Ed!
Previous Topic:Compilation errors found when running a transformation inside the jboss container
Next Topic:QVT 1.2
Goto Forum:
  


Current Time: Thu Nov 23 01:55:26 GMT 2017

Powered by FUDForum. Page generated in 0.01577 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software