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
.