Type Patches for MetaEdit+ 3.0

A type patch is a special kind of repository patch, a file that makes changes to the contents of your repository. A type patch contains the definitions of a number of types, i.e. metamodel elements, in general a graph type and all of the other types it uses or needs. Type patches are thus a way to transfer metamodels from one repository to another, allowing distribution of new languages or changes to them, for example allowing use of an organization-wide standard at several sites, each with their own repository.

Creating a Type Patch

Type patches can be created by any user, using the 'save selected types' popup menu item in the Type Manager. See the help (? button) in the Type Manager for more details.

Using a Type Patch

Type patch should have been made by an image with the same patches installed. It is recommended to make a backup of your repository before using a type patch. Basic instructions for using a type patch are as follows:

Log in as sys-admin, with no other users
Choose to open all projects
Choose a default project for new types
From the MetaEdit+ Main Launcher, select 'Repository'->'Options' menu
From the Options Tool that opens, select the Repository page and press 'File in Patches'
Type the type patch file name in the top pane of the window that opens and press Enter (Figure 1)

Figure 1. File List browser Window.

The middle field should now list all patch files
To load a patch, choose it in the middle pane and choose 'file in' from its popup menu
Check that the changes seem to have worked, and if so exit with commit

When filing in a type patch you should first open all projects, to make sure that all existing types in your repository are loaded. This ensures that if the patch contains updates to existing types, the existing types are changed, rather than new types being created; if new types were created, your database would contain different versions of the same type in different projects, leading to fatal errors. You should also set the default project to be the one where you want any new types from the patch to be created. Note that a new subtype of an existing type will however be created in the same project as the existing type.

Instances are changed to reflect changes in their types in the same way as changes made via the metamodelling tools. All changes affect attempts to create new data; some also affect attempts to modify existing data; some also change existing data instantly. The general approach is to preserve data that is likely to be important. For instance, removing an object type from a graph type preserves existing objects of that now illegal type in graphs of that type, because removing all those objects would cause the loss of much data, including the objects, their properties, relationships and roles. For smaller changes, e.g. removing a single property from an object type, the loss is less significant and so the property is removed from instances.

Graph: Explosion and decomposition rules: preserved; Legal bindings: preserved; Legal object types: preserved
Object, Role, Relationship: Symbols: next time editor is opened; Property dialogs: instantly; New properties: added instantly when object is in image; initialized when property read; Deleted properties: removed instantly when object is in image; Changed property type: preserved; Made property unique: affects creations and modifications
Property: Widget: affects only the creation of new property dialogs; ensure dialogs using this are consistent

For additions of properties, as soon as an attempt is made to read the new property (e.g. by opening a property dialog, displaying a symbol that includes that property, reading its value in a report), the object is marked as changed and a new property created for it with the default value. In a single user repository this presents no problems: objects are updated as necessary and invisibly to the user. In a multi-user repository the lock to update the object may fail (another user may already have updated it in an overlapping transaction). In this case the object is updated, but not marked as changed, and the user is warned. When this user starts his next transaction after the other user's update has been committed, the other user's updated version will be read.

Whilst this should not present any problems, if there are many such objects the dialogs may be annoying, and thus it is recommended that after updating types sys-admin should try to read as many such added properties as possible, e.g. with a report.