Handle Relation Types

Relation type handling has changed in version 5. In version 4.x it was possible to have implicit relation types for any field in an article. In version 5 this is no longer the case: only relation types that are explicitly defined in the content-type publication resource are allowed. In addition, relation types names are resolved in the same namespace as fields, so a relation type may not have the same name as a field.

In order to avoid naming problems, when the Migrator encounters such ad-hoc relations in exported data, it auto-generates a relation type name by adding the suffix _RELATED to the field name.

These auto-generated relation types, however, are not included in the converted content-type resource generated by article-to-content-types.xsl.

This means that if your 4.x publication made use of such undefined relation types, then you will need to add definitions for them to the content-type resource created by article-to-content-types.xsl. If, for example, your old articles contained relations to fields called title, then you would need to add a relation called title_RELATED to your content-type resource, as shown below:

<field type="basic" mime-type="text/plain" name="title">
...
</field>
<relation-type-group name="news-relations">
  <relation-type name="title_RELATED"/>
</relation-type-group>

Fields and relation types were allowed to have identical names in 4.x article type definitions. This is not normally the case, however, for version 5.2.7.2 content-type definitions. If your 4.x article type definitions contain identical field and relation type names, then errors will occur when you try to upload the converted content-type resource. You can prevent this happening by setting the /neo/io/services/validators/ContentTypeValidator component's enableSameNameForFieldAndRelationType property to true. By default this property is set to false.