Content Server Manual / Version 2201
Table Of ContentsThe Content Server does not support automatic renaming of content types, as it is hard to detect this situation without additional operator assistance. So you have to do some changes in the content types definition files and in the database.
Note that you may also have to adapt various parts of your application, such as Queries stored in the
repository, link list properties in Structs, template file names and EL expressions in templates, generated
ContentBeans etc.
In the following, you find a description to consistently rename content types in the doctypes.xml
file and in the database and to update Struct properties.
Make sure that all Replication Servers (and other repository listeners) are idle, that is, that there are no pending events in the Content Server's
ChangeLog. Otherwise, events might refer to an incorrect content type name later.Stop the Content Management Server and all Live Servers.
Rename the content type in the content type definition file, including the
Parentattribute of all subtypes and theLinkTypeattribute of allLinkListPropertys.Rename the database table that represents the content type to the new name. Depending on the database, this is possible using either an
ALTER TABLEstatement, or by creating a new table, copying all data, and deleting the old table.Rename occurrences of the content type name in the Resources table:
UPDATE Resources SET documentType_ = 'myNewName' WHERE documentType_ = 'myOldName'Rename occurrences of the content type name in the Rules table:
UPDATE CmRules SET docType = 'myNewName' WHERE docType = 'myOldName'If you have Struct properties with link lists that reference the renamed content type, you have to adapt the
LinkType. In principle, you have several options to do the update of theLinkType. However, the one described here is the one which introduces the least downtime. The update consists of the following steps:Add a new abstract content type with no properties to the content type definition file. Give the content type the old name of the renamed type and also the same parent as the renamed type.
Add the new abstract content type as the parent type to the renamed content type.
Restart the Content Server. Everything should work as before. That is, the Content Server won't fail to start and your editors may continue to work. As the intermediate content type is abstract, they won't be able to accidentally create contents of this type.
Change the
LinkTypeof the Struct properties to the new content type. If you have content queries, also change the content type if necessary. You can write custom UAPI clients for these tasks.When you have finished the update, remove the new content type from the content type definition file.
Restart the Content Servers.
Adapting the ChangeLog
If point 1 (idle repository ChangeLog) cannot be ensured, you can proceed as follows:
Truncate the
ChangeLogas far as possible, as described in Section 3.11, “Truncate the ChangeLog”.Update all
ChangeLogentries that refer to content type names (the column depends on the event code):UPDATE changelog SET s2='myNewName' WHERE s2='myOldName' AND i1 IN (1, 2);UPDATE changelog SET s1='myNewName' WHERE s1='myOldName' AND i1 IN (36,37);After restarting the Content Server, all clients connecting to this server will only see the new content type name in content repository events.
Existing content of the renamed type needs to be reindexed in Content Feeder
and CAE Feeder indices. For the Content Feeder,
use the JMX operation "reindexByType" of Content Feeder
Mean com.coremedia:type=AdminBackgroundFeed,application=content-feeder with the new name of the
content type as first parameter and value "type" as second parameter ("aspect") to reindex
the contents. For the CAE Feeder, you need to reindex from scratch.
See Section 3.5, “Reindexing” in Search Manual for details.
