Content - external store data restructuring

Owned by Pradyumna Nagendra
Last updated: Dec 10, 2019
1 min read

Introduction:

This wiki explains the current structure of external store data for content and the proposed changes in the structure to bring consistency.

Background & Problem statement:

Content-TypeIdentifier in Neo4JIdentifier in CassandraVersion 0

Version 1..10

Data
ECMLdo_123do_123Draft, LiveLiveDraft and Live version object have the same format for the data.
do_123.imgdo_123.img
Draft
Collectiondo_123do_123.imgDraft
Draft version will not have the root-object metadata.
do_123do_123LiveLive
do_123.imgdo_123.img
Draft

Design:

Option 1:

Content-TypeIdentifier in Neo4JIdentifier in CassandraVersion 0

Version 1..10

Data
ECMLdo_123do_123Draft, LiveLiveDraft and Live version object have the same format for the data.
do_123.imgdo_123.img
Draft
Collectiondo_123do_123Draft, LiveLiveA draft version will not have the root-object metadata.
do_123.imgdo_123.img
Draft

Implementation Changes

  1. Get hierarchy API for Live version(without mode=edit) should validate status in Cassandra data and throw resource not found if status is not part of hierarchy data
  2. In publish pipeline, read data from neo4j and based on identifier from neo4j, fetch hierarchy data from Cassandra
  3. Migrate hierarchy data of draft collection content which does not contain pkgVersion in it.

Option 2:

Content-TypeIdentifier in Neo4JIdentifier in CassandraVersion 0

Version 1..10

Data
ECMLdo_123do_123 LiveLiveDraft and Live version object have the same format for the data.

do_123.imgdo_123.imgDraftDraft
Collectiondo_123do_123 LiveLiveA draft version will not have the root-object metadata.
do_123.imgdo_123.imgDraftDraft

Implementation Changes

  1. Changes required to store draft version in external store for create, update and read contents
  2. Publish pipeline changes to read ECML draft only from do_id.img
  3. Migrating all draft ECML content with do_id.img