04-11-2019 06:11 AM
Hello,
I have a little issue I don't know how to tackle properly and concerns performance.
I need to process ~200k documents that are missing an aspect. First, I identified these documents with a mysql query to evaluate how many there are. These nodes have aspect X but are missing aspect Y, so I need to add aspect Y to all these nodes.
I'm exploring the BatchProcessor approach right now and I am basing my code on the class org.alfresco.repo.node.db.NodeStringLengthWorker. Is this the correct way to do this ?
Few questions arise from writing my code :
- what's the best way to get the nodes in the WorkProvider : searchService solr/lucene ? nodeService ? nodeDAO.getNodesWithAspects (here I would have to check each node for the missing aspect) ?
- how do I stagger this search ? I see in NodeStringLengthWorker we use minNodeId and maxNodeId, is this a way to reduce the search load ?
I saw there was a talk https://community.alfresco.com/thread/214163-deleting-over-1000-nodes#comment-716898 about this subject but this link is not working anymore.
Our production environment is very frail so this process should really produce as less load as possible.
Thanks in advance, and if you need any more info I will provide gladly.
04-17-2019 06:07 AM
I've create a sample project available at:
Include the QName of the aspect you are adding in alfresco-global.properties to test the module.
Let me know if this works for you.
04-11-2019 07:14 AM
IMO the best approach is to use REST API with pagination. So you can patch documents by blocks.
04-11-2019 11:06 PM
Thanks for your answer Angel.
Can I ask you to be more specific on your approach ? How would you get these nodes, /search endpoint ? And how would you patch them, /nodes/{nodeid} PUT ?
I need to prevent changing the modifier/modified properties while doing this and prevent all behaviour for performance could be a good idea.
04-12-2019 12:24 AM
This is mainly the idea, get the nodes with "/search" pages and add the aspect with "/nodes/{nodeid}".
You can disable AUDITABLE Behaviour to avoid the change of the modification properties.
04-12-2019 03:21 AM
Hello,
Thanks again for your help. My solution is working now just I have to decide on the number of nodes to fix per loop performance wise. It takes around 7s for the transaction that fixes 20 nodes to finish.
One thing I can't prevent and is fundamental to approve my code is the change in modification properties. In my transaction I do a behaviourFilter.disableBehaviour(); then reenable at the end, but the nodes still show "Modified by System".
I see in the logs that as soon as I reenable the behaviours a few other custom behaviours trigger on these nodes and modifiy them, I suppose if they use current user context then this must be why modified & modifier change to System ?
Any idea how to solve this if my supposition is right ?
Explore our Alfresco products with the links below. Use labels to filter content by product module.