MGNLUI-3972 - Getting issue details... STATUS
Problem
Most content apps use info.magnolia.ui.framework.availability.HasVersionsRule rule for checking whether node has version or not. This rule is executed every time node is selected in content app, meaning Jackrabbit tries to cache calls to version history. While this can be ok for smaller installations, large installations can suffer performance issues because Jackrabbit cache (8MB by default) cannot store all content in its cache and needs to refresh it.
Goal
Provide solution to avoid excessive access of availability version rule to the version store.
Proposal
Add new mixin mgnl:hasVersion that will be added or removed by VersionManager, similar like VariantManager, that handles adding and removing mgnl:hasVariants mixin.
Pros & cons
very easy to implement
very easy to check whether node has versions
no need to store information about versions in any cache / class / etc.
proven solution by personalization
removing versions other way that using VersionManager can lead to inconsistencies
complicated update task? (adding mixin to already versioned nodes)
Implementation
Should be pretty straightforward, adding and removing of the mixin will be handled by VersionManager, plus rewriting the HasVersionRule action to check for mixin instead of getting all versions from version store.
Update task and its solution
Needs to be verified, if such expensive update task would "kill" Magnolia on update or not. If yes, we would then need to run such task later (after update, via scheduler?) to ease load on the instance.
Summary
Update task:
- test on a large data set (use scheduler job in case of "failed" update process)
- make it defensive (add option to magnolia.properties that will disable the task)
- crawl mgnlVersion workspaces if possible and try to find base node
Other:
- Add mixin to the NodeTypes class
- Implement in VersionManager (this is the only place where Magnolia allows to create versions)
- Adjust UI action