Model Generation Options

You can affect the model generation for persistable items with various annotations and properties. This document contains an incomplete list of some of these.

Note: this package contains the EMF-generated interfaces for the Repository component's model. These classes are internal to the Repository component, and must not be referenced from other components except from the EMF-generated code for their model.

Table of Contents
  1. Annotations

    1. Provisional annotation

  2. Properties

    1. Unique Property

1 - Annotations

EMF allows you to define arbitrary annotations on practically any artifact, including models, packages, classes, enums, and features. The annotation itself has a name and includes a set of key-value pairs known as details. They are available at runtime, and we use them to affect behavior. Some of the annotations we use are described below.

1.1 - Provisional annotation

One of the drawbacks of our in-place migration strategy is that it is very difficult to change model additions, especially once they have been included in a milestone. This makes it difficult to collaborate with other components or products on functionality that depends on a new model without either using a split stream or fully committing to the model before the collaboration can really get started. Provisional models were introduced to address this.

The provisional annotation is an annotation on a class or feature. You may only use it on a brand new class or feature. When a model element has this annotation, it will not have any effect on normal operation. No database artifacts will be generated for this model. This means that you can completely change or remove the provisional model aspects at any point without affecting production databases.

To enable the provisional part of the model, you define a Java system property before creating databases, and also for servers running against such databases. You should realize that any databases created with provisional models can be used for testing purposes only, and will stop working once your model graduates out of provisional status. When using this, you typically will first deliver model changes with this annotation applied to the new parts of the model. You and your collaborators can then continue to develop your new feature on top of this model. Once you are ready to commit to the model, you remove the annotation, regenerate the model code, and deliver.

The annotation uses two details, both of which are required. One required detail is propertyName. This is used to specify the java property to use to enable the provisional model aspects. The other required detail is version. You set this to any string to label the version of this provisional model. If you later decide that you need to make a change before promoting the model out of provisional status, you can choose a different version string. At this point, any databases built using the first version of the model will be prevented from working with the new version of the model.

2 - Properties

EMF defines properties that you can set on packages, classes, attributes, and features. You can modify these properties using the Properties view when the appropriate artifact is selected in the EMF Editor.

Some of these properties are self explanatory, such as Name or Default Value. Others have meanings that are specifc to the Jazz persistence framework. Some of those are described below.

2.1 - Unique property

This is a property on a reference or attribute. It is only meaningful for lists (i.e. features where the Upper Bound is greater than 1). For non-queryable lists, when this value is set to true, we will throw an exception when someone attempts to save an item that has duplicate values in this list.

We do not allow non-unique queryable lists. If unique is set to false on a queryable feature, we spit out a warning to the log file during activation, and still enforce list uniqueness.