We have a content structure for a type ‘publication’ that has a folder for publications, within that a folder per ‘publication type’ and within that year and month folders.
When a publication is created, a DerivedDataFunction populates a govscot:publicationType property on the new publication based on the type folder. This works but we had not realised that in doing this a hippo:related property linking the publication to the folder is also created. The path we use is:
/publicationType:
jcr:primaryType: hipposys:resolvepropertyreference
hipposys:relPath: …/…/…/…/…/govscot:publicationType
Over time the size of the folders has become quite large with some publication types having 15K publication or more. The issue we have is that when a new year folder is created within the type folder the hippo:related means that the derived data functions for each variant of each publication is called causing the cms to become unusable.
Is there a way for us to have a DerivedDataFunction that does this without creating the relationship? We tried accessing jcr:path bit this does not seem to be available to us. We can get the jcr:uuid but with no session being available in the derived data function that does not really help us.
Thanks for any suggestions on how we can work around this,
David
PS,
I see this past question along similar lines where Woonsan notes that the path is not available
The hippo:related property is set in the DerivedDataEngine. I think the property is only set if the node is mix:referenceable, but I wouldn’t just go ahead and remove that mixin, if it is even allowed by the cnd (don’t know of the top of my head). So basically, no you can’t change that.
You could consider a job that cleans these properties from folders. I don’t think you need that property to be maintained. Probably. Test it on not production.
We have written a migration that can clean these up to fix the performance issue.
I would like to be able to get the path from the derived data if possible though. @woonsanko mentioned in the previous ticket that accessing the path would be a reasonable improvement, if we raised a ticket would this be likely to be picked up?
In the meantime I have attempted to do it locally but have hit a snag. I have started by overriding the class:
with my own implementation. This class currently supports the ancestors property and seems like the right place. I have not been able to get this working yet though since the namespace for hipposys has this:
meaning I cant add a ‘path’ property in the config for my derived data function. Is there a way for me to override that definition in the namespace to be:
I can’t make any promises on any type of feature request. I suggest taking this up with your account manager and pushing it from that end. There are always more feature requests, product improvements, upgrades, and bug fixes then can be handled in the short term. So it is a matter that product management needs to see the need for the request.
IIUC, it’s the setting of the hippo:related property. You would have to avoid the DerivedDataEngine to achieve this I think. You might consider a more custom workflow event handler, or even custom scxml actions to achieve this.