Bug 145709 - Unstable saves and loads. Classes name becomes dirty and large parts of graphs disappear.
Summary: Unstable saves and loads. Classes name becomes dirty and large parts of graph...
Status: RESOLVED FIXED
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Oliver Kellogg
URL:
Keywords:
: 145042 147179 147848 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-05-20 14:58 UTC by Guillaume CLEMENT
Modified: 2007-07-13 19:43 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
First file that became to be bugged (70.44 KB, text/plain)
2007-05-20 15:01 UTC, Guillaume CLEMENT
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume CLEMENT 2007-05-20 14:58:54 UTC
Version:           1.5.6 (using KDE KDE 3.5.6)
Installed from:    Ubuntu Packages
Compiler:          gcc 4.1.2 (Ubuntu 4.1.2-0ubuntu4) 
OS:                Linux

I have worked on a file for several days. After some time, some classes with weird names began appearing in the base folder of my Logical View.

Then today some of my classes were ignored during the save, and probably replaced by those garbage names. This names include 0mnIAwusAZw4, 8fHE9LAVNPMw, ... When a class disappears, all of the information that I put inside diagrams that were related to these classes also disappear.

I have this kind of output in the console :

umbrello: ERROR: UMLView::addWidget: Not adding (id=Zgvdw4Mw2PqB/type=313/name=DrawManager) because it's already there
umbrello: ERROR: UMLView::addWidget: Not adding (id=6DHrxS7g5T26/type=313/name=SoundManager) because it's already there
umbrello: ERROR: UMLView::addWidget: Not adding (id=S7UwQRIKytP1/type=313/name=InputManager) because it's already there
umbrello: ERROR: UMLView::addWidget: Not adding (id=3zBTjPUlvy8m/type=313/name=Input) because it's already there
umbrello: ERROR: UMLView::addWidget: Not adding (id=gSly3bdXTamy/type=313/name=Core) because it's already there
umbrello: ERROR: UMLView::addWidget: Not adding (id=1RRULjSdCaje/type=313/name=AIInput) because it's already there
umbrello: ERROR: UMLView::addWidget: Not adding (id=HzAqLqFnbZju/type=313/name=KeyboardInput) because it's already there
umbrello: ERROR: UMLView::addWidget: Not adding (id=dEQ0gZm8mIWH/type=313/name=JoystickInput) because it's already there
umbrello: ERROR: UMLView::addWidget: Not adding (id=geUHWBnsHu0C/type=313/name=IPInput) because it's already there


Working on this file make the situation go even worse. I tried to reproduce the problem by working on a new file but I didn't succeed. I can provide the files so that you can try it by yourself. With the current file I have, an easy way to reproduce the problem is :

1. Delete all the rubbish classes names.
2. Delete the class Core which was duplicated for some reason.
3. Put the interface Core into "Plugins overview" view along with some messages between Core and DrawManager for instance.
4. Link the note "Main loop;..." to Core
5. Save
6. Reload

--> The weird classes appear again (I have tested the case while writing this).

It's my first bug report and I have no idea how I can provide you with the files though so don't hesitate to mail me.
Comment 1 Guillaume CLEMENT 2007-05-20 15:01:04 UTC
Created attachment 20639 [details]
First file that became to be bugged

This file is the one which gives me a lot of problems. When working on it you
can see the behaviour I'm describing.
Comment 2 Oliver Kellogg 2007-05-21 23:30:32 UTC
Analysis:

Classes were removed that were still referenced by some other model elements.
For example, the bogus class "27" has xmi.id="4kANtf55Jden" which is
referenced by the fileName parameter type of the nouvelleOperation of the
DrawManager interface. On encountering an object reference that cannot be
resolved, Umbrello creates a surrogate class with an artificial name
(such as "27" or worse) in order to at least resolve the dangling reference.
Comment 3 Oliver Kellogg 2007-05-22 06:12:03 UTC
SVN commit 667185 by okellogg:

resolveRef(): When m_SecondaryId cannot be resolved and m_SecondaryFallback
is empty then set m_pSecondary to the artificial datatype "undef".
This is somewhat less friendly on loading older Umbrello files but avoids
the creation of bogus objects.
The better way to solve this bug would be to warn the user when he attempts
to delete model objects that are still referenced somewhere in the model
but I'm afraid I cannot implement that right now.
CCBUG:141279
BUG:145709


 M  +1 -0      ChangeLog  
 M  +12 -7     umbrello/umlobject.cpp  


--- branches/KDE/3.5/kdesdk/umbrello/ChangeLog #667184:667185
@@ -1,6 +1,7 @@
 Version 1.5.71
 
 * Bugs/wishes from http://bugs.kde.org:
+* Unstable saves and loads, class names become dirty (145709)
 * Crash on deleting class in list view (145762)
 
 Version 1.5.7
--- branches/KDE/3.5/kdesdk/umbrello/umbrello/umlobject.cpp #667184:667185
@@ -414,16 +414,21 @@
             maybeSignalObjectCreated();
             return true;
         }
-    }
-    if (m_SecondaryFallback.isEmpty()) {
-        if (m_SecondaryId.isEmpty()) {
-            kError() << "UMLObject::resolveRef(" << m_Name
-                << "): both m_SecondaryId and m_SecondaryFallback are empty"
-                << endl;
-            return false;
+        if (m_SecondaryFallback.isEmpty()) {
+            kDebug() << "UMLObject::resolveRef: object with xmi.id=" << m_SecondaryId
+                << " not found, setting to undef" << endl;
+            UMLFolder *datatypes = pDoc->getDatatypeFolder();
+            m_pSecondary = Object_Factory::createUMLObject(Uml::ot_Datatype, "undef", datatypes, false);
+            return true;
         }
         m_SecondaryFallback = m_SecondaryId;
     }
+    if (m_SecondaryFallback.isEmpty()) {
+        kError() << "UMLObject::resolveRef(" << m_Name
+            << "): cannot find type with id "
+            << m_SecondaryId << endl;
+        return false;
+    }
 #ifdef VERBOSE_DEBUGGING
     kDebug() << "UMLObject::resolveRef(" << m_Name
               << "): could not resolve secondary ID " << m_SecondaryId
Comment 4 Oliver Kellogg 2007-06-05 21:32:02 UTC
*** Bug 145042 has been marked as a duplicate of this bug. ***
Comment 5 Oliver Kellogg 2007-06-25 06:57:32 UTC
*** Bug 147179 has been marked as a duplicate of this bug. ***
Comment 6 Oliver Kellogg 2007-07-13 19:43:25 UTC
*** Bug 147848 has been marked as a duplicate of this bug. ***