Re: Undo/redo implementation & JMI compliance

I possibly missing something in prior discussion.
My usecase for undo/redo are graphical editors.
For them undo /redo is limited to user session.
Undo/redo is very unsuitable for concurrent
or long term access to repository.

There seems some other usecase for it that is assumed
in discussion, please provide pointers to prior discussions
or describe such use case.

Brian Smith wrote:

> Constantine and everybody,
>
> I think that even without undo/redo, having the diagram item contain a 
> reference to the model element will cause problems. In general, it 
> seems like a bad idea to create long-lived references to JMI instance 
> objects because the JMI implementation is free to create multiple 
> instance objects to represent a single modeled element. For example, 
> if you have code:
>
> boolean isContainerIdentical(ModelElement me) {
>     return me.getContainer() == me.getContainer();
> }
>
> This code could very well return false since the JMI implementation 
> could create a new instance object each time me.getContainer() is 
> called. So, potentially you could have a some diagram elements that 
> reference the "same" model element, but referencing different instance 
> objects.

Could you please provide  pointers to spec that suggest such behaviour?
Such behavior is very surprising to programmer and it is very easy to
prevent this in implementation. If specification allows it, I think that 
it is
an issue with specification that should be risen.

>
> Also, I would expect that MDR and other persistent JMI repositories 
> would make good use of weak referencing to provide memory-efficient 
> transparent persistence. But, if your diagram elements contain strong 
> references to the model elements, this will be (partially) defeated.
>
> So, in my view, no long-lived objects should contain references to JMI 
> instance objects. Instead, everything needs to be done by a map 
> (mof-id -> application-data). And, if you have this designed into your 
> whole application, it seems a simple matter to add a little 
> indirection to keep track of which objects have been "recreated" with 
> a new ID, like this (untested):

I expect that editor that need undo/redo will mosly have
document oriented "load/edit/save" model of work rather
then repository  model "chekout/edit/commit". Possibly
there are usecases when metadata is much less like the
document, but I doubt that undo/redo will do any good
for such case as undo/redo model had been developed
for "load/edit/save" model of work and may work or not
work for other models of work.

Perisitent reference to element will be using mofid or
similar mechanism. But in-memory reference directly to
model element is very reasonable solution for graphical
editors as it will avoid unneeded lookup and will
reduce memory consumption and simplify code.

>
> class ObjectIdentityMap {
>     synchronized RefObject getObject(String mofId) {
>         Object replacement = replaced.get(mofId);
>         if (replacement == null)
>             return repository.getObjectByMofId(mofId);
>          else
>             return repository.getObjectByMofId((String) replacement);
>     }
>     synchronized void replaceIdentity(String oldId, String newId) {
>         Object oldReplacement = replaced.get(oldId);
>         if (oldReplacement != null)
>             replaceObject((String) oldReplacement, new);
>         replaced.put(oldId, newId);
>     }
>         // String oldId -> String newId
>     WeakHashMap replaced = new WeakHashMap();
> }
>
> Then the diagram objects would keep track only of the MOF ID (and the 
> identity map), and the problem you described should go away. But, this 
> does require that the JMI implementation provide a method like 
> "getObjectByMofId()".

This method had been suggested for JMI, but I do not
remember why it has not got into spec.

Constantine