BUG - Model-importer doesn't update some information (access type, influence strenght...)

[jbsarrodie]

As discovered in #740

Here's a reproductible example of the bug:

• Create a model A and add an an Application Component which accesses a Data Object. Set the relationship to read/write.
• Create an empty model B and import A into it.
• Now in B, change the access relationship to be juste "access" (i.e. no read nor write)
• Import A again into B and make sure you allowed updates.
• In B, access should be back to read/write but it isn't.

This is because ModelImporter#updateObject() only updates Name, Documentation, Properties and Features. So the same issue exists in the following cases:

• Access type
• Influence strength
• Junction Type
• Association directed flag

The agreed approach to solve it is to make ModelImporter#updateObject() more generic so that it updates all EStructuralFeature.

I'm working on it.

[Phillipus]

There are some useful refactorings in the specialization-modelimporter branch that you should build on, too. So maybe best to continue in this branch rather than working in master

[jbsarrodie]

There are some useful refactorings

Ok, I was not aware of it.

[Phillipus]

Some useful info:

• All actions are done as Undo/Redo Commands
• Because Commands are used, we have an Object Cache in ModelImporter that keeps track of existing objects and newly added objects in case a Command occurs where an object has not yet been added to the Model but can be referenced in the cache

[Phillipus]

Ok, I was not aware of it.

It might make it harder to merge everything.

[Phillipus]

I don't know if a generic Ecore type method will be able to do what we are doing in UpdatePropertiesCommand and UpdateFeaturesCommand where we are replacing all properties and features.

[jbsarrodie]

Just pushed a generic update of EAttribute (using commands)

I don't know if a generic Ecore type method will be able to do what we are doing in UpdatePropertiesCommand and UpdateFeaturesCommand where we are replacing all properties and features.

It won't and I don't think it makes sense to do it differently (your approach for properties and features is already generic).

[Phillipus]

My OCD is playing up with your git commit comments. Can you put a space between the commit message and any further comments? ;-) (Otherwise it shows on all one line in SmartGit)

[jbsarrodie]

My OCD is playing up with your git commit comments. Can you put a space between the commit message and any further comments? ;-) (Otherwise it shows on all one line in SmartGit)

No pb ;-)

BTW, I'm assuming that we'll squash these commits (the last one triggers my own OCD...)

[Phillipus]

BTW, I'm assuming that we'll squash these commits (the last one triggers my own OCD...)

Yes, I can tidy up anything as well.

I figured out how to do a commit but set the author to someone else.

[jbsarrodie]

I figured out how to do a commit but set the author to someone else.

Temporarily change your email?

[Phillipus]

Temporarily change your email?

No, it's something in SmartGit. Commit locally and then choose "Edit Author..."

[Phillipus]

I've updated the specialization-modelimporter branch.

• Tided up your generic updater to a updateEObjectFeatures() method
• Taken your ideas from specialization-modelimporter-byname branch and use Name and Class for Profile's unique key. Simplified this to use one object cache and single set of methods
• ProfileImporter updates imported Profile instead of cloning

TODO: Objects needs to refresh in Views and Properties tab if a Profile/Image has changed. This worked before because I was (wrongly) making a clone of the Profile and re-adding it which would force a refresh in the UI. Now I need to force a refresh if Profile is updated.

[Phillipus]

Problem now is if a Profile is renamed in the source model and target model was using it. That's not working...we end up with two Profiles with the same ID.

[Phillipus]

1. Source model has Profile: "P1", "id123", "BusinessActor"
2. Target model imports
3. Source model changes name of "P1" to "P2"
4. Target model imports and now has P1 and P2 with same ID

And:

1. Source model has Profile: "P1", "id123", "BusinessActor"
2. Target model imports
3. Source model changes name of "P1" to "P2" and creates a new Profile "P1", "id456", "BusinessActor"
4. Mess

[jbsarrodie]

Problem now is if a Profile is renamed in the source model and target model was using it. That's not working...we end up with two Profiles with the same ID.

I know, that's were I left before working on ModelImporter#updateObject(). This doesn't only affect model importer but also coArchi. And if we store images with the original file name instead of a hash, then it might happen that two images have the same path...

So I was trying to figure out the best way to solve this...

[Phillipus]

And if we store images with the original file name instead of a hash,

Actually, its not a hash, just a generated ID.

[jbsarrodie]

• Source model has Profile: "P1", "id123", "BusinessActor"
• Target model imports
• Source model changes name of "P1" to "P2"
• Target model imports and now has P1 and P2 with same ID

No, we first lookup Profiles by ID, and only by Name+Type if no ID matches. So it will get renamed (at least it was with my implementation).

And:

1. Source model has Profile: "P1", "id123", "BusinessActor"
2. Target model imports
3. Source model changes name of "P1" to "P2" and creates a new Profile "P1", "id456", "BusinessActor"
4. Mess

Same, matched by ID first wins.

The only issue I see is (assume same concept type for profiles):

1. Source has profile "P1"
2. Target has profile "P2"
3. Import Source into Target
4. Target now has "P1" and "P2"
5. User rename "P1" to "P2" in Source
6. Import again Source into Target
7. Source "P1" is renamed to "P2, we now have two profiles named "P2" for the same concept type

[jbsarrodie]

Actually, its not a hash, just a generated ID.

Damn it autocorrect ;-) That's what I wanted to write

[Phillipus]

No, we first lookup Profiles by ID, and only by Name+Type if no ID matches.

OK, I'll refactor to do this and see what we get.

[Phillipus]

Now findObjectInTargetModel() checks for an existing object by its ID, then if not found by name + class

[jbsarrodie]

OK, I'll refactor to do this and see what we get. Now findObjectInTargetModel() checks for an existing object by its ID, then if not found by name + class

Good. I'll test later today.

The only issue I see is (assume same concept type for profiles):

1. Source has profile "P1"
2. Target has profile "P2"
3. Import Source into Target
4. Target now has "P1" and "P2"
5. User rename "P1" to "P2" in Source
6. Import again Source into Target
7. Source "P1" is renamed to "P2, we now have two profiles named "P2" for the same concept type

For this, I think we could raise an error, or merge them and raise a warning (user can then decide to undo).

This also makes me think that it would wake sense to offer a way for users to "merge" specialization. For example one can decide to have two specialization SQL DataBase and NoSQL DataBase, and later decide to merge to only on DataBase. Not urgent now but for another release someday (jArchi will solve it in the meantime).

[Phillipus]

For this, I think we could raise an error, or merge them and raise a warning (user can then decide to undo).

Or rename one of them by adding a suffix or prefix P2 (2).

[jbsarrodie]

Or rename one of them by adding a suffix or prefix P2 (2).

That's another option.

In fact, maybe we should have a new option in the import wizard: Import and merge profiles by name:

• When enabled (which should be the default) we use the lookup by name in addition of the lookup by Id and two profiles having the same name (in any cases) are merged (with a warning).
• When disabled, we only lookup by Id and raise an error if we end up with two profiles with the same name.

[Phillipus]

Heads up - I've rebased the specialization-modelimporter branch on top of new changes in the specialization branch.

[Phillipus]

Thinking about your merge option ideas...why not import all Profiles by ID first and then if there are duplicates by name then merge these with a rule that the source is the winner or the target is the winner? We can't really "merge" because we have to choose which image to use.

[Phillipus]

Note: The specialization and specialization-modelimporter branches have been rebased onto the latest master branch.

[jbsarrodie]

Closing this issue as original bug has been solved