Labels: B -> Branch, S -> Schema, SV -> Schema Version, N -> Node, NC -> Node Content
When updating a schema, a new version is created and all nodes have to be migrated to the new version. A migration creates a new node content for every node which is costly when there are many nodes in that schema. Because of that, schema migrations should be avoided when possible. Nodes only have to be migrated when structural changes have been made to the schema (one or more fields have been added, deleted or changed). However, currently a migration is triggered even when only non-structural changes have been made (#185). This proposal aims to eliminate these unnecessary migrations.
Proposal
The proposed schema model looks like this:
Labels: SSV -> Schema Structure Version
There is now an additional type of node in the graph, the Schema Structure Version. A new SSV will only be created when a structural change has been made. When a non-structural update has been made, only a new SV will be created and no migration is necessary.
Pros
No migrations for non-structural changes, including: Changing description, autoPurge, container, Elasticsearch settings or the proposed schema control properties (#170)
For non structural changes to the Elasticsearch properties, the reindex API can be used. This should be the most efficient way to change mappings.
Cons
Changelog entry will be executed on first start with the new Mesh version which will affect all node contents. That will cost some time once.
Tasks
Create new model type
Create changelog entry
Change logic of schema update / node migration
Check all edges between schema version and node content and alter all operations that use them
Use reindex API for non structural Elasticsearch changes
Motivation
The current schema model looks like this:
Labels: B -> Branch, S -> Schema, SV -> Schema Version, N -> Node, NC -> Node Content
When updating a schema, a new version is created and all nodes have to be migrated to the new version. A migration creates a new node content for every node which is costly when there are many nodes in that schema. Because of that, schema migrations should be avoided when possible. Nodes only have to be migrated when structural changes have been made to the schema (one or more fields have been added, deleted or changed). However, currently a migration is triggered even when only non-structural changes have been made (#185). This proposal aims to eliminate these unnecessary migrations.
Proposal
The proposed schema model looks like this:
Labels: SSV -> Schema Structure Version
There is now an additional type of node in the graph, the Schema Structure Version. A new SSV will only be created when a structural change has been made. When a non-structural update has been made, only a new SV will be created and no migration is necessary.
Pros
Cons
Tasks