GitLab

It was discovered on customer projects that category table can contain a significant amount (15% and 22% were reported) of rows in category table where category_uid is the uid of a Base Category document. Given the very few use cases where this makes a difference, this is considered (by myself, @tb and @jerome ) a waste of disk space and hence of performance/scalability, and should be dropped.

This change prevents any Base Category document from appearing in the category_uid column, reducing category table size.

There are 3 separate review parts in this merge request, one per commit:

• CMFCategory.CategoryTool: Stop using selection_{report,domain}: This commit is preparatory work. I think selection_{report,domain} is overkill and exactly equivalent to this replacement. Anyone knowing selection_{report,domain} spotting a difference ? This commit can be pushed independently from the rest of this merge request if it is considered fine. I expect some performance improvement due to the large quantity of code being avoided, though I did not measure it (it is not the main goal here, just preparing for 2nd patch).

• CMFCategory: Do not index any Base Category as a related document.: This is the main change. Please answer the following questions:

  • Do you consciously rely somewhere on a related key selecting all documents bearing a relation to everything inside a given base category ?

  • Given an hypothetical "group/region/europe" relation ("group" is the relation type, "region/europe" is the related document, which happens to be a category inside another base category), do you think the document should be found when searching for portal_catalog(group_uid=group.getUid())? And when searching for portal_catalog(group_uid=region.getUid()) ? Please motivate each affirmative response with arguments strong enough to justify a 25% increase to stock table length (20% decrease is symetric with 25% increase).

• ERP5.Tool.SimulationTool: Fix support for related base categories.: This change is optional. I would prefer not to push it, given the huge amount of keys it adds and the potential subtle change. Is anyone consciously passing a base category when filtering catalog results (ex: node_category="account_type" or similar) ? What is the intended effect ?

/cc @alain.takoudjou @aurel @cedric.leninivin @jerome @jm @jp @romain @seb @tb : this touches a critical part of ERP5. Please bring more nexedians to the discussion if you think it is appropriate.