Impact of schema changes on the graph server

The following section explains the different types of entity and entity definition changes in Sitecore Content Hub™, as well as their impact on the graph server.

Data in Content Hub consists of content types known as entities (for example, assets, products, or projects). The data schema is defined by the properties and relations that are created through member groups. An entity definition consists of one or many member groups.

Changes in entity definitions

The changes made in the entity definitions are categorized into the three following groups:

  • Content changes
  • Validation changes
  • Representation changes

Changing entity definitions also changes the structure of the data. Be careful when changing existing entity definitions.


For more information on Entities, see Entities.

Content changes

Content changes include any change to the entity definition, which can be directly represented by the entity model (alteration of relation flags, inheritance, new or removed members, and so on).

This group of changes can be further divided into two subcategories:

  • Changes that affect descendants: this is most of the changes, because of the relations between entities.
  • Changes that do not affect descendants: this is the minority of the changes to entities, for example, the addition of a property not included in full-text content or the addition of a relation which does not provide any form of inheritance.

Validation changes

Validation changes include any changes to the rules that are enforced on the entity definition or the corresponding entity save. They include:

  • Any changes to entity definition member mandatory flags.
  • Any changes to mandatory member conditions.
  • Any changes to mandatory validation cultures.
  • Any changes to regular expressions or validation expressions of the property definition.
  • Any changes to mandatory rules/conditions of a parent or a child.

Representation changes

Representation changes include any changes related to rules that are used to represent the entity model via the external API (for example, the REST API). These rules are therefore not essential to the form of the existing entity model. They include:

  • Any changes to allow updates flag.
  • Any changes to allow navigation flag.
  • Any changes to is nested flag.
  • Any changes to the list of nested properties.
  • Any changes to nested permissions flag.
  • Any changes to is rendition relation flag.

Changes in entities

Due to the existence of the entity schema in the form of entity definitions, there is only one type of changes in entities. The changes to the entities include:

  • Changes of the values of system properties (for example, modified on, is locked).
  • Changes of the values of properties.
  • Changes of the linked entities via the relations in the form of a difference set.
  • Changes of entity relation properties (for example, inherit security flag).

Data flow in the entity model

The entity model can be represented as a directed graph, allowing us to use various forms of the inheritance. The graph is built on this principle to deliver the expected effects. The basic types of inheritance are as follows:

  • Taxonomy inheritance: the entity has a taxonomy hierarchy attached to it and can be searched for using this taxonomy (faceting).
  • Path inheritance: the full path is available on path enabled entities.
  • Topology inheritance: the entity inherits directly from its parents.
  • Content inheritance: the entity inherits the full-text content of its ancestors.
  • Completion inheritance: the entity has the completion content of its ancestors.
  • Security inheritance: the entity inherits security from its ancestors which defines the entity access.

This model creates numerous possible configurations. Examples include:

  • Entity content, which should be included in the full-text search, has been changed: this change will require an update of the entity itself as well as any descendant with content inheritance.
  • Entity has been locked: as this information is not part of any inheritance, only the relations of this particular entity need to be updated.
  • Entity was removed from the system. Therefore, any descendants connected via relations/inheritance need to be updated.

Order of dependency

The basic principle is that any change to the entity or the relation's information, which is visible to the entity or to a descendant of the entity via inheritance, needs to be fully propagated so that none of the related entities in the system contain outdated information.

The previous concept of the inheritance creates a natural order in the entities (for example, parents, children, grandchildren), and in the entity definitions (for example, there is data flow from asset definition entities to file definition entities but not the other way around).

This concept is an order of dependency, representing dependencies of several objects towards each other. There are entities and entity definitions with less dependencies (high hierarchy entities) and those with more dependencies (low hierarchy entities).


The changes made to the high hierarchy entities or entity definitions can impose a substantial workload on the graph server, as explained in the next section.

Services provided by the graph server

The graph server provides an environment with an in-memory entity data model representation, providing fast ancestor traversal and content retrieval.


For more information on the system stats and the graph server, please see Stats.

The graph server provides the following modules:

  • Elasticsearch graph worker: responsible for the creation of denormalized search service documents, making it active after any change to the entity's data model.
  • Business audit graph worker: responsible for creating audit entries from any event in the system, including those not affecting the entity's data model.

Effects of the changes on the graph server

Any change in the system translates to the following succession of events in the graph server:

  1. If the event describes a change to the entity data model, the graph model is updated.

  2. If the graph model is updated, any graph worker listening to the graph changes is notified to apply all the effects of the event (for example, ElasticSearch graph worker exports all affected entity–bound search service documents).

  3. If the graph model is intact because the event did not change the entity data model, any graph worker listening to such non–modifying (meta) events are notified to perform specific actions (for example, business audit graph worker creates an audit entry while using existing graph data to compose rich context information).

The following events do not modify the graph model in any way:

  • Validation changes of the entity definition.
  • Representation changes of the entity definition.
  • Events not related to direct changes or deletion of entities, entity definitions and data sources.

The following events reload the graph model:

  • Content entity definition changes affecting descendants reload all the entities of the corresponding entity definition, and all the entities of the dependent entity definitions.
  • Content entity definition changes not affecting descendants reload all the entities of the corresponding entity definition, and all the entities of the directly dependent entity definitions (for example, children).
  • Entity changes reload the corresponding entity and any descendant entity which inherits any information from this entity according to the principle mentioned above.

The changes made to the high hierarchy entities or entity definitions can impose a substantial workload on the graph server.

Can we improve this article ? Provide feedback