Bug 578821

Summary: Update persisted e4 elements with new information
Product: [Eclipse Project] Platform Reporter: Lars Vogel <Lars.Vogel>
Component: UIAssignee: Platform-UI-Inbox <Platform-UI-Inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3 CC: Lars.Vogel, rolf.theunissen
Version: 4.22   
Target Milestone: ---   
Hardware: PC   
OS: All   
Whiteboard:

Description Lars Vogel CLA 2022-02-18 04:35:23 EST 
Currently the framework persists the model elements. If the data in the development model changes the persisted data is not updated.

For example:

- Closeble flag
- Icon
- bundleclass
- Label

Existing RCP clients typical use a workaround for this, e.g. by using a model add-on which updates the entries or the -clearPersistedState startup option.

Plug-in contributions do not seem to have this issue. We should implement a similar approach for e4 contributions.
Comment 1 Lars Vogel CLA 2022-02-18 04:36:53 EST 
Rolf, do you have an idea how this could be implemented? My take would be to implement a model process which re-reads the model fragments and compares the existing model with this read model but I hope their is a more efficient way.
Comment 2 Rolf Theunissen CLA 2022-02-19 06:58:45 EST 
I think this would be implemented with model-fragments, and tag them to apply always. However, model fragments do have many issues, see Bug 562497, so I don't know it it currently works out of the box. If the current 'alway' or 'exists' do not cover your use-case you could add a 'force' or something.

Besides the elements in the model or fragment, some elements get created when running the RPC. e.g. Parts and Placeholders are created from PartDescriptors, in these cases some kind of model update (model processor) is need to migrate the model and to update the state of the generated elements.

In general, this update should only run if the Part or Placeholder has defaults only. However, as properties are copied, we cannot be 100% sure if something is a default or set fixed to a value that is the same as the default.
EMFs 'unsettable' might support this behavior, that is, if the value is not set use the default. However, this would require much code changes to handle this correctly in the platform. That is, e.g., take tags from a Placeholder of its Part or PartDesciptor when not set.

For RPCs in controlled environments the model update should work.