Closed tortmayr closed 4 years ago
I didn't notice any such issue with EMF-generated IDs, so that sounds like a reasonable solution to me (I use the Notation XMI:ID to map to the GModel ID).
You may want to ensure that the EMF Resourse uses unique IDs though (The default strategy in EMF is to use positional IDs, so you might get the same kind of issue). Typically, using XMIResource#useUUID = true provides good results
Yeah, that's what we planned to do as well on the EMF model server side (UUIDs). :+1: I wouldn't enforce it for all use cases though, but I guess it should be the default on the model server and we maintain the IDs for the GModel generation, to have stable IDs across editing operations and model updates.
Resolved with #382
(from #309 ) The way we generate IDs is index-based. That means, if we delete the second-last node, the last node (before the deletion) gets the same ID as the second-last node before the deletion. Thus, Sprotty will animate the model as if the last node becomes the deleted second-last node. I think, we'll have to discuss how we address this issue. I guess the original EMF models should eventually provide stable IDs that we can reuse as IDs for the GModel. This way, we avoid reassigning the ID of deleted to another node and consequently avoid this issue. What do you think?