erp5_knowledge_pad: drop complicated and broken logic to wait that new pads are indexed
This fixes many different bugs, like random Unauthorized errors when a knowledge pad is deleted. When an object is created, calling immediateReindexObject is only a performance coding crime, which should be negligible since pads are objects that are not created often. Previous implementation was certainly even less scalable due to the many extra requests done to wait that new pads are indexed. If immediateReindexObject is too slow, a distributed cache could be used instead. This is not trivial and overkill for the moment. It would be better if we didn't have to rely on the catalog. IOW, data could have been organized differently so that in ZODB, pads are grouped in containers, 1 per user.
Showing
This diff is collapsed.
Please register or sign in to comment