Unexpected Caching?

[Calem Bendell]

If you open two instance of Minueto to edit to files at one time, the changes you save in one file are not reflected in the other file, even after deleting the extension and reimporting the concern or reimporting the RAM model.

I wasn't able to find code in TouchCORE that performed caching of opened files. Confused.

[Matthias Schoettle]

What do you mean with "open two instance of Minueto [...]"?

If you mean running two instances of TouchCORE and editing the same file, if you save it in one, the other will still work with the model in its memory. I.e., you would have to close it there and reopen it.

[Calem Bendell]

I run two instances of TouchCore (sorry, was a bit tired :D), edit one file, save it, close it, then I go to the next TouchCore instance, delete references to the file, reload the ram file, and the file is unchanged. This seems odd.

[Matthias Schoettle]

Ah I see. I'll have to check that. It should be unloaded, but there might be a problem with that.

[Matthias Schoettle]

The problem is that unloading only happens when the scene for an aspect is closed (i.e., switched somewhere else from it).

So it doesn't happen when the instantiation is deleted, maybe we should unload the aspect in addition, since it cannot be open anywhere else anymore.

[Matthias Schoettle]

Resolved issue #198: The scene of the lower-level aspect is destroyed when exiting the split view. Also, when deleting an instantiation, the aspect's resource is unloaded in case it was loaded without the scene (when mapping manually).

→ <<cset e94a03096076>>

[Matthias Schoettle]

When closing an aspect scene, all referenced aspects (in the instantiations) need to be unloaded as well.

[Matthias Schoettle]

References #198: Adds unloading of referenced aspect models from instantiations when closing an aspect scene. This completes the possibilities, since removing the instantiation unloads the resource otherwise.

→ <<cset 884bbc96f062>>

[Matthias Schoettle]

A similar thing happens during a concern reuse, i.e., the reused concern and the copy is not unloaded once the aspect scene is closed. This might need to be done once the reuse is finished. I did not realize this is related to the caching problem.

For example, when reusing a concern, undoing, fixing the concern, reusing it again (with same features), the result of the woven model is the same as the previous woven model. This occurs, because the previously loaded models are still in the resource set, which prevents them from being loaded again. The resource of the woven model is a new one, since it was unloaded.

[Matthias Schoettle]

References #198: Updates unloading of external resources to include all of them (i.e., those from model reuses and the regular instantiations).

→ <<cset 831a4682a2f0>>

[Cécile Camillieri]

Maybe we only want to unload resources for woven elements, and not for the ones that are part of the current concern. For instance when we open a concern, all Models are already loaded, because the Aspects Container needs to access them.

But when we go back from an aspect, it's unloaded, so the container has only a proxy reference to it and will not be updated properly. This particular problem has been fixed for now by refreshing the container everytime we enter the scene. But it's not really something we want to do.

Here is another example of a problem caused by this unloading:

• Create a new Aspect.
• Save it and go back to the concern.
• In the concern, associate this aspect to a feature of the model. The aspect in memory will be modified to have this reference to the feature.
• Do not save the concern.
• Go to the aspect view and don't modify anything.
• Go back to the concern view. Since we didn't modify the aspect, we don't save it. When we leave the scene, the Aspect is unloaded, so the fact that it realizes the feature is now lost. This can easily lead to inconsistent models.

Since we know all the aspects anyway in the concern scene, maybe it is not necessary to unload these. Of course we still want to unload temporary resources, like the woven models.

[Jörg Kienzle]

That sounds like a great idea!

• J

[Matthias Schoettle]

A note from the ECSE429 project: Initializing ResourceManager with caching = false did not prevent it from caching. Still, a loaded model had to be unloaded before it could be loaded again.

[Matthias Schoettle]

Seems to be resolved.