The Content Management Server maintains stable and universally unique identifiers (UUIDs) as specified in RFC 4122 for content items and versions. Existing and newly created contents and versions get a random UUID in addition to existing numeric content IDs and version numbers. UUIDs are not meant to replace existing IDs, and IDs can be used for all purposes as before. Note, that UUIDs are currently only available on the Content Management Server, and not on live servers.

Upgrade:

The Content Server automatically adds new database table columns for UUIDs when started. This affects both management and live servers. If the database is Microsoft SQL Server or DB2, then you have to set the configuration property sql.schema.alterTable=true once when starting a Content Server .

Note, that it is not possible to start a Content Server of a previous release on the database after the new Content Server has adapted the database tables. You should always make a backup of the Content Server database before upgrading. This is even more important for this change.

The Content Feeder now feeds the content's UUID and the UUID of its latest version. To this end, the fields uuid and latestversionuuid were added to the Solr schema in apps/solr/modules/search/solr-config/src/main/app/configsets/content/conf/schema.xml . You can invoke the Content Feeder 's JMX operation reindexAll of MBean AdminBackgroundFeed with the aspect parameter set to "uuid" to set UUIDs of already indexed content. The Search Manual explains re-indexing in general in section "Search Engine | Reindexing | Partial reindexing of Content Feeder indices". It is recommended but not required to perform this re-indexing step.

UUIDs for existing content and versions are generated lazily on the Content Management Server when the content or version is accessed the first time after the upgrade. This entails a small performance penality, but only for the very first access. If you follow the recommendation to let the Content Feeder index UUIDs for existing content as described above, then lazy generation of most UUIDs will happen early as side-effect.

Unified API:

In the Unified API , the following methods have been added for UUID support:

The event classes ContentCreatedEvent , ContentDestroyedEvent , ContentRevertedEvent , and VersionDestroyedEvent also got new constructors that take an additional UUID parameter. The existing constructors without UUID parameter have been marked as deprecated. Furthermore, the existing method ContentRepository#getContent(String) can now also be called with a content UUID's string representation to lookup a content by its UUID.

If the Unified API is connected to a live server or to a server of a previous release, then methods that would return a UUID will return null instead.

The Unified API Developer Manual mentions UUIDs in the new section "The Content Repository | UUIDs".

Tools:

(CMS-16509)