What is the problem you are trying to solve?
Delete operations for journal articles are very costly in terms of performance when they include a very large amount of fields.
What is your project about? (e. g. Intranet, Partner Portal, Enterprise Website, etc)
This request comes from a critical performance issue observed by a customer when trying to delete journal article versions. This customer has a massive number of webcontents, versions and fields within each of them. They’ve been working with this approach from 7.1 to 2024.q1 so far, and they already told us it is impossible for them to change it.
What is your proposed solution? (optional)
The issue has already been analyze for a long time in several tickets. The full context of the case is included in both:
While core team was able to improve create and update operations, they found the deletion process is more complex because it performs operations on all versions of the web content article. Under normal circumstances this should be pretty quick. But because each version of the client’s web content has around 129 unique fields and as associated 13.9K+ rows in DDMField/attribute (from our testing), there is still a multiplicative effect in processing all versions so it is expected that the deletion process would take longer.
The conclusion was the following:
If we want to provide a more impactful fix, that would require more investigation into architectural changes on the DDM side
So I’m creating this feature request as per their conclusions. Please see this comment for more context.
Thank you