Refactoring content type classes

When refactoring content type classes there are a few things that are beneficial to be aware of. This document explains how basic refactorings are handled and what you need to consider when refactoring your content type. All supported refactorings are considered non-destructive: in other words no existing data will be removed.

Renaming of a content type class or a property

Renaming a content type by GUID

When renaming a content type class a new content type will be created as long as no GUID is specified in the ContentType attribute of the class. If there is data on the old name, in other words if there are pages created with the old name, then the old page type will remain and the old pages will use the old content type. When viewing this content type in admin mode under the Page Type or Block Type tab the old content type will be marked as it is missing its code. If there is no data, the old content type will be deleted.

If a GUID is specified in the ContentType attribute and the GUID matches an existing content type it will be renamed and any old data will use the renamed content type. The GUID of an existing content type is available in admin mode when editing the basic information for a content type.

Renaming by API

When renaming a content type or property using the specific API you need to create a migration step class. The migration step class must implement one method named AddChanges. There you have the possibility to specify what content types or properties has been renamed and what they used to be named. This will ensure that the existing properties will be renamed and retain any values they had before the rename. The API is based on strings as that is the only reasonable way for us to know the names of old types and properties.

The following example shows how to rename both a content type as well as a property on that content type:

using EPiServer.DataAbstraction.Migration;

namespace CodeSamples
{
    public class MigrationStepExample : MigrationStep
    {
        public override void AddChanges()
        {
            RenameContentType();
            RenameProperty();
        }

        private void RenameContentType()
        {
            //The content type formerly known as "Velocipede" should hereby be known as "Bicycle".
            ContentType("Bicycle")
                .UsedToBeNamed("Velocipede");
        }

        private void RenameProperty()
        {
            ContentType("Bicycle")                  //On the content type "Bicycle"
                .Property("PneumaticTire")          //There is a property called "PneumaticTire"
                    .UsedToBeNamed("WoodenTire");   //That used to be called "WoodenTire"
        }
    }
}

Deleting a content type class or property

When a content type or property is deleted from code the system will sync the database as much as possible without deleting any data (values saved on any page). It will use the same notion as when a content type or property is renamed. If there is no data, the content type or property is deleted from the database. If any data is present, the content type or property will remain and be marked in Admin mode as it is missing its code.

Changing the type for a property

Generally speaking, change of type on a property is not supported if there is data stored in the database. But under certain circumstances it is possible to change type of a property. Any existing data will try to be converted to the new type. If the conversion is not successful an error will be logged and nothing will be committed.

The prerequisites are enforced because a type change in code should not be responsible for any data loss. Therefore the following prerequisites must be fulfilled for the a change of type to be possible when there is data stored in the database.

• The old value must be settable to the new type OR parsable in the ParseToSelf method of the new types backing PropertyData.
• The value of the backing PropertyData you are changing to must implement the System.IConvertible interface.
• The backing PropertyData must also have its Type property set to any of the seven first values of the PropertyDataType enumeration.
• Neither the old or new property type is a block.
• If the new type is String, then any old value cannot be longer than 255 characters.

If a change of type is needed and any data loss is acceptable then you must change the type of the property in admin mode. To be able to change the type of a property in admin mode the property must temporary be removed from the code.

Deleting culture-specific attribute on a property

When changing a property from being culture-specific to not being culture-specific there is a possibility that the change will not be reflected on the site. This happens when there is culture-specific data stored in the database. In that case an error will be logged but no change will be made to the property in the database. To go through with this particular refactoring, you need to go to admin mode and change the setting manually.