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.