| [e4-dev] Persisted Application Model & Model Evolution |
Hello e4-Team, working on Bug 389624 I have stumbled onto another flaw in the current way the framework handles the persisted model when fragments are used to extend a base application model. I could invest some time to work on this. Before I start though, I would be happy about some opinions. Suppose you start with this simple application model: - Application (ID: app) - TrimmedWindow (ID: window) - PartSashContainer (ID: sash1) - PartStack (ID: stack1) - PartStack (ID: stack2) With some contributions in a fragment: - StringModelFragment (ID: stack1, feature: children) - Part (ID: part1) - StringModelFragment (ID: stack2, feature: children) - Part (ID: part2) - Part (ID: part3) After loading the base model and the fragments, the application model looks like this: - Application (ID: app) - TrimmedWindow (ID: window) - PartSashContainer (ID: sash1) - PartStack (ID: stack1) - Part (ID: part1) - PartStack (ID: stack2) - Part (ID: part2) - Part (ID: part3) After the application is started the user can drag/drop part3 and drop it in stack1 next to part1. Closing the application, this will be persisted in workbench.xmi: - Application (ID: app) - TrimmedWindow (ID: window) - PartSashContainer (ID: sash1) - PartStack (ID: stack1) - Part (ID: part1) - Part (ID: part3) - PartStack (ID: stack2) - Part (ID: part2) So far, so good. The problem arises on the next start of the application. First, the model from workbench.xmi is loaded (as above). Next, all the fragments are loaded and the contributions are added/replaced in the model. Currently, this is achieved by merging the contributions into the parent defined by the StringModelFragment. Since part3 is contributed to stack2 and stack2 does not have a child with that id, the part will be added to the list. The resulting model looks like this: - Application (ID: app) - TrimmedWindow (ID: window) - PartSashContainer (ID: sash1) - PartStack (ID: stack1) - Part (ID: part1) - Part (ID: part3) - PartStack (ID: stack2) - Part (ID: part2) - Part (ID: part3) This is not what was intended and leads to all sorts of problems. So the question is how to handle a persisted model. I have the feeling that the situation is not quite clear when a persisted model (workbench.xmi) is present, since the original model (Application.e4xmi) is not merged, but fragments are. One possible solution would be to just not merge the fragments, since the elements are included in workbench.xmi anyway. This leads to another question: How does the framework handle model evolution? I am thinking about this approach: 1) Load the model from workbench.xmi (without additional fragments and processors) 2) Load the application model and merge all fragments and run all processors 3) Compare the two models, removing all elements which are not present in (2) and adding all elements which are present in (1) This processing could be disabled by a flag (i.e. –checkForModelEvolution). Any thoughts? Regards Christoph -- |