MGNLUI-3972 - Getting issue details... STATUS
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.
Provide solution to avoid excessive access of availability version rule to the version store.
Add new mixin
mgnl:hasVersion that will be added or removed by
VersionManager, similar like
VariantManager, that handles adding and removing
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)
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.
- 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
- Add mixin to the NodeTypes class
- Implement in VersionManager (this is the only place where Magnolia allows to create versions)
- Adjust UI action