any gotchas re exporting EA and importing into new empty project?

[verhoefw]

Hi all,

We have a 20+M model that is several years old for which compacting doesn't change the file size much.  I have tested out exporting the model to XMI 2.1 and importing it into a new, empty project which results in a file that is less than 10M in size.  I've explored the file and not found any losses yet, but I'm wary about what we might be missing besides any orphaned tidbits we tried to delete in the first place.  Are there any gotchas?  Any recommendations or things to beware of?

Thanks,
Wendy

[qwerty]

A) reference data (pictures, EA specialities like issues etc.)
B) audit log
C) baselines

That should be the non-XMI part. There might be more. You could alternatively try a project transfer first which should not loose any of the above.

q.

[verhoefw]

Hi q,
Thanks so much for your reply.  I tried out a few things based on your suggestions, trying to narrow down what content could make such a big difference:
- I tried a project transfer but unfortunately it made the file size half a meg bigger;
- I made a copy and dropped the diagrams that had pictures/graphics, but the file size didn't go down (though I checked and we did lose the graphics in the imported copy - I hadn't realized that would happen and hadn't checked that, but we can reimport those if necessary),
- I checked and we didn't have auditing turned on so there was nothing in the log
- we haven't done baselines so that couldn't account for it.
So I'm in a quandary about what to try next to determine what else we might lose by doing the export/import.  Any further suggestions? 
Thanks so much!
Wendy

[KP]

qwerty's reference data suggestion still sounds possible. ribbon|Configure|Model|Transfer|Export Reference Data and tick everything, then import into the new model.

[qwerty]

Another thing (that should be done regularly) is to run a project integrity check.

I have no idea what Mickeysoft Access is offering on a tool base. Maybe there's something that can determine table sizes. I would write a little Perl or Python script to query the single tables and spit out their size. That would at least give an  indication where to look.

Of course: switching from EAP to some real database would be a remedy for such a disease.

q.

[Uffe]

Hi Wendy,

In addition to what qwerty listed above, there are all sorts of things that get stored in a project but which are not part of an XMI export (which really only contains what you see in the project browser).

The ones I can think of which can take up significant space are

D) document generation templates
E) images
F) linked documents

I'm not sure whether images are included in an XMI export. They might be.
Linked documents might possibly be included as well (less likely).

A project also contains scripts, code generation and model transformation templates, and all sorts of other configuration stuff ("reference data"), but that's mostly text and so doesn't take up much space. What q and I have listed is stored as binary data blobs, so it's both bulky and difficult to deal with for the DB engine.

/Uffe

[qwerty]

You can tell the XMI export to include images. Don't know by heart where exactly, but likely somewhere in the options jungle.

q.

[Eve]

If you're truly exporting from one project into an empty project. Just use the Project Transfer function. That will include all most and reference data content.

Otherwise, XMI for the model content and reference data for everything else that you need.

[qwerty]

She did that and it increased the size of the DB (someone else reported the same observation recently).

q.

[Paolo F Cantoni]

She did that and it increased the size of the DB (someone else reported the same observation recently).

q.

If the transfer project is to an EAP file, then it should be compacted after transfer.  We find on our large snapshots (800Mb+) we get a 25% reduction in file size.

Sparx has confirmed that for this and other reasons, not compacting (automatically) after a Project Transfer is a defect that will be rectified sometime.

Paolo

[verhoefw]

Hi all,

Thanks for all these replies.  I've since tried several things and figured I'd report on them:

- Per the Sparx Team, I tested out exporting reference data to see whether one of those options could be the culprit and it appears that the Project > Model Images export came out as nearly 17M!

- Per Querty's additional suggestion I did a Project Integrity Check which resulted in a fairly small set of issues for a 300+ class UML model so I figured these aren't inflating the size:
  1 - Invalid attribute name. ITEM: Attribute: 10141. ACTION: Set Attribute Name to <unknown>.

  2 - Invalid attribute name. ITEM: Attribute: 2561. ACTION: Set Attribute Name to <unknown>.

  3 - Invalid link geometry. ITEM: Missing Diagram. ACTION: Delete Invalid Link Geometry.

  4 - Invalid connector. ITEM: NoteLink. ACTION: Delete Connector.

  5 - 2: missing GUID's. ITEM: Attribute GUID. ACTION: Update GUID's.

  6 - Invalid attribute. ITEM: . ACTION: Delete Attribute.

  7 - Invalid attribute. ITEM: . ACTION: Delete Attribute.


- Per Uffe's suggestion I exported the RTF Document Templates and Template Resources and they were less than .4M; exporting reference data for images I had checked already and we don't have any linked documents in our model

- I checked if I could import images as Querty suggested and only found an option to import diagrams, which we were doing already (class diagrams etc. imported just fine, but we had loaded some graphics in several diagrams and those images were missing in the EAP populated by importing the XMI)

- As Paolo suggested, I also tried compacting after the project transfer but it only shrank the file by .7M - probably because we had already compacted the file fairly recently.

All I've tested so far leads me to conclude that the biggest culprit is our model images in several diagrams.  I tested saving them as .bmp, .jpg, .png and .tif (saving as .gif kept crashing my MSWord) and .jpg was by far the smallest size but apparently that's what we loaded into the EA diagrams in the first place.  So I think we might consider dropping those diagrams from the model and loading them on the website for reference instead.

Again, thanks so much to all who replied!  It was a big help to explore all those options!
Best,
Wendy