| Summary: | non-deterministic behaviour of transformation | ||
|---|---|---|---|
| Product: | [Modeling] QVTo | Reporter: | Philipp Kalb <philipp.kalb> |
| Component: | Engine | Assignee: | Project Inbox <mmt-qvt.operational-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ed |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Philipp Kalb
There is no repro for this, but a likely scenario is that anything that involves a Set has a non-deterministic order. In principle this is just tough, but it is a nuisance. An incremental execution requires an input model comparison and an update execution requires a model output comparison. If these comparisons are based on stable hashes, the hashes could be re-used to define a stable execution order for currently indeterminate activities. Perhaps needs an execution option - indeterminate order - determinate order - reversed determinate order - random determinate order subject to a given random number key Much of this functionality can be shared by QVTd and may need to originate in OCL. (In reply to Ed Willink from comment #1) > Much of this functionality can be shared by QVTd and may need to originate > in OCL. (Pivot) OCL Bug 509726 suggests that indeterminacy is not in accord with the OCL specification and outlines an approach whereby Pivot OCL will become determinate. |