Up Previous Title Page Index Contents

3.4 Importing and type deletion

3.4.1 Importing methods and models

In MetaEdit+ the system administrator is responsible for importing methods and models exported from other repositories into his repository. This section describes the importing functions and gives guidelines for applying it in typical scenarios.

Method patches and model patches

There are two type of repository patches that system administrator can file into the repository: method patches and model patches. Method patches include only types, and are made with the Type Manager (see Method Workbench User’s Guide). Model patches include instances (design data) together with their types (method). This patch is made with the Graph Manager (see MetaEdit+ User’s Guide). Both types of patch are imported in the same way.

Repeated export and import

Importing will affect large amounts of data, and must perform complicated mappings from the structure and contents of one repository to another. It is thus worth spending time making sure you understand a little of what happens during import, especially if you want to repeatedly export and import from one repository to another, called the source and target repositories here.

The target repository remembers from which source repositories imported instances have come, so if the same graphs are exported again later, the existing imported instances in the target repository are updated, rather than creating new ‘duplicate’ instances. Previously imported instances will thus be updated in the correct project automatically, if the source repository name given when exporting the previously imported patch was the same as for this patch. Exporters should thus take care to always use the same, unique name for the source repository when exporting.

Recognising previously imported types to be updated is based on unique internal names, stored with each type, and is thus not dependent on the name given for the source repository when exporting (exporting only types does not ask for a source repository name). When importing, you are expected to first open all the areas when types to be updated exist. If a type is imported that already exists in another, unopened project, MetaEdit+ will warn you and ask for permission to open that project.

Whilst updating types works in any repository, updating instances works only in one direction: from the source (exporting) repository to the target (importing) repository or repositories. It is not possible to update the exported models in the source repository by importing the same models back from the target repository.

Similarly, if A exports to B, and B exports to C, it is not possible to update models in C by directly exporting from A. Instead, B must import the models from A, and then re-export them for C to import. In many situations, it would be better for A to export one patch at the start, which both B and C could import. Later, A could export the newer versions of the same models, and again both B and C could import that same patch.

Instructions for importing

The normal state for importing is to have just logged in: if you are already logged in, and have a sufficiently recent backup of the repository, you can continue from step 3. Make sure however that no editor or browser windows are open during import.
1)Before importing either kind of patch you should take a backup of your target repository.
2)Start MetaEdit+ and log in to the target repository as system administrator.
3)Open all projects containing types (at least those types that might possibly also be in the patch to be imported), and also those projects where you want new types and/or instances to be created.
4)Select a default project: you will be prompted during import to choose a default project for new types, and a possibly different default project for new instances.
5)Select Repository | Options in the Main Launcher and choose the repository page’s File in Patches button. A Patch Browser opens, and you should type the filename in the top pane, choose the patch to import in the middle list, and select file in from the middle list pop-up menu.

You can watch the progress of the import from the Launcher’s transcript. After the import, briefly check the imported models and types before committing. Check especially that new types and instances have been created in the projects where you expected them, and that previously imported instances have been updated, rather than new ‘duplicate’ instances created (which would indicate that the name given for the source database when exporting this patch was not the same as for the previous patch).
Note that all your designs (instances) - also those that where not imported - are changed to reflect changes in the method (types) in the same way as changes made via the metamodelling tools.

Import-Export Scenarios

This section describes some scenarios of how the import/export functionality might be used:
Simple model exchange

 If one user simply wishes to give a model to another user, he can export it to a file and the other user can import it, even if the second user has totally different methods in his repository (although in that case the second user should be aware that the types of the imported methods will be created in his repositorythe currently default project). He may wish to create a new project to hold the first user’s models and methods.
One source, many targets

 A common situation is that one developer or organisation is working on a set of core models, and other developers or organisations are each working on their own sets of models, which reuse and refer to these core models. The core developer or organisation can export the current state of their repository (the source repository), or just the relevant parts of it, to a file. This file can then be imported into an empty repository, and the resulting repository (the target repository) can be given to each other developer or organisation. (If the others have already started work, the file is simply imported into their existing repositories).
 Work continues in both source and target repositories. Whilst the core developer or organisation need not see the changes made by the other developers or organisations, the latter must keep their repository up to date with the changes made to the core models. Thus the core developer or organisation periodically exports the changed or new core models to another file, and this is then given to each other developer or organisation, who import it into their repository. When exporting, the same name should be given each time for the core (source) repository, so that imports into target repositories update the core models there rather than creating new ones.
Versioning

 If a model created in a repository is exported and then imported to the same repository, it creates a full copy of that model and all its components, but uses the existing types. This is useful for making versions: the current state is exported and considered as frozen as a version in its project, a new project is created and the file imported with the new project as default. This creates a new working copy in the new project, and development can continue with that. This process can be repeated as often as necessary, always exporting the current working version and thus freezing it, importing it into a new project and continuing work in that new project. As the same data is never exported twice, it is in principle safe to give the same source repository name each time when exporting; in practice, it may be wiser to give a different name, avoiding problems if you export from a frozen project by mistake.
There is absolutely no connection between the data in the frozen version and the new working version: changes in the new version will not affect the frozen version. Users should no longer change the frozen version; their work from now on should happen in the new project.

Hints for importing and exporting

Exporting uses large amounts of memory. If you see a lot of cache reclaiming, try setting higher values in Fine Tuning (see 3.3.2).

You can export and import from the same source repository to the same target repository many times; subsequent imports update existing imported objects, providing the database name specified when saving the model patch was the same each time.

You cannot import changes back from the target repository to the source repository (this just creates new copies the first time, then updates them on subsequent occasions).

There is no warning if existing types are to be replaced by ‘smaller’ or ‘older’ versions, causing existing property data from your own models to be lost.

There is possibly a danger of Graph Manager updates never ending if cache reclaim happens often — be patient though, as it often takes a while, especially if there are many models.

Graphs not selected on the left in the Graph Manager, but reachable from those selected (e.g. explosion, decomposition, reused elements), are exported as empty graphs, i.e. with just their properties, but no contents. The same is true for graph types in the Type Manager.

3.4.2 Removing types

The Type Manager is a tool for exporting method specifications, and deleting no longer needed parts of methods. Here we focus on deleting types: exporting methods is covered in the Method Workbench User’s Guide:

Deletion of methods or parts of methods — types — that you do not need reduces the size of your database and thus improve speed, in particular the time taken to open a project. This permanent removal is in addition to the removal of types that can be done from the Types Browser: removing a type in that way only removes it from most system dialogs, and it remains in the database, and can be salvaged at any time. Type deletion with Type Manager, on the other hand, is a once and for all deletion operation, and as such we advise taking a backup of your repository before performing type deletion.

Type Manager can be opened from the Launcher by choosing Metamodel | Type Manager. Type Manager shows all the methods and their component types in currently open areas. You can see the methods on the left, and expand the display with the check box underneath the list to show all the component techniques (Graph types) of those methods. The Type Manager works on the principle that the user can be sure what methods he needs, but may be mistaken in thinking that a given type is not needed: that type may in fact be used in some complex way from another type that he does want.

In the list on the left in the Type Manager you choose all the methods and techniques that you want (initially all are chosen), and press the button. MetaEdit+ calculates the dependencies between types: this involves loading all those types, so will take a while the first time. The list on the right then shows all the types in the open areas, ticked if they are required by the methods you have selected on the left. Types in the list on the right that are not ticked will be deleted when you press the Delete Unselected Types button.

Before deleting types, check to see that the graph types unchecked in the left list are also unchecked in the right list. If a graph type that you thought would be deleted is still checked in the right list, you can choose Show Type Users... from its pop-up menu in the right list, and will see which types you have chosen to keep still refer to it. Most often, they will refer to it by explosion or decomposition links, and you may want to remove these links from the chosen types, to allow this unwanted graph type to be deleted.

You can use the Type Manager freely to look at types and their dependencies, without deleting anything. When you want to delete, you should make sure that you have all projects open, and that the metamodelling security level is set to exclusive, to ensure nobody else logs in.

All instance graphs whose types are to be deleted will be removed, and explode or decompose links to those graphs will be removed. Under normal circumstances, this will ensure that there are no instances left in the repository of types which are to be deleted. You are however responsible for making sure that no other instances of types to be deleted exist. This problem occurs most often with object types previously in a graph type, but now removed: as no graph type refers to that object type, it would be deleted, but it may still have instances in graphs made when that object type was legal.

The types will then be deleted in two phases, with a transaction commit at the end of each phase. You will then be prompted to exit and restart MetaEdit+, to ensure that no references to the deleted types are present in your image, and to perform a database garbage collect, which will reclaim the space occupied by the deleted types.









Up Previous Title Page Index Contents