GREYSummary of finding and ideas identified while looking at possible ways to implement MGNLDMS-137@jiraGREY
- Create version of documents on public instance during activation
- Provide means so serve different versions of same document via paragraphs
Versioning is inherently possible in any workspace and
dms workspaces on public instance are not an exception. To enable versioning on public instance as part of the activation process it is necessary to open a hook for command chain (to allow arbitrary execution of any command). Commands in the chain have to be configurable and have to be differentiated per workspace (same as on the author during activation).
Additional work to be done if proceeding with the above:
- Activation integration test suite is necessary to ensure current activation process is not adversely affected by the change.
- Parallelization of activation (Activating multiple documents at once) has to be preserved.
- While implementing the change in m-m-exchange-simple, XA activation needs to be re-tested as well to ensure no impact as well.
- As a result of execution of versioning command, whole activation will be significantly slower (first guess is about 50% - from 2 secs per doc to 3 secs per doc)
- Size of the public database will grow significantly faster then before.
- Any future upgraded would have to be performed twice - once for author instance and once for public instance since each of them can have different versions. Upgrading only author and activating all content to fresh public instance would mean the versions on public would be lost during such upgrade.
- With the above implemented, it is still possible to only activate current version of the document from author, and such document will be versioned on public instance no matter whether versioning on author is enabled or not.
- It will not be possible to activate any arbitrary version of document into same version number of same document on public. Versioning schemas of each instance are independent.
- When versioning content templates are not versioned as they are stored in file system only, hence displaying old version of content may be affected by template changes (e.g. fields existing previously, but removed in never version of template will not be visible when browsing previous versions of content). Same limitation already applies to all content versioned on author.
- how to write paragraphs that could deal with displaying arbitrary version of given document? Do we need to do anything extra to facilitate that?
- do we need to do anything about security (like add extra permissions to versions)?
- if this change is to be implemented in Magnolia itself rather then as extra module, it means quite big change and doesn't qualify as minor/bugfix release.
- Do we really want this in core of Magnolia?