One example of this is bug 109718. Here's another example: Say, I navigate to the "Categories" tab in the "content" content section in order to delete the "Education" category: |select category_id, name, default_ancestors |from cat_categories |where name = 'Education'; | | category_id | name | default_ancestors |-------------+-----------+------------------- | 100 | Education | 61/100/ |(1 row) The "Education" category has the following three subcategories: |select | cccm.category_id, related_category_id, cc.name as related_name |from | cat_category_category_map cccm |inner join | cat_categories cc on (cccm.related_category_id = cc.category_id) |where | cccm.category_id = 100; | | category_id | related_category_id | related_name |-------------+---------------------+-------------- | 100 | 101 | Arts | 100 | 102 | School Time | 100 | 103 | Literacy |(3 rows) Before the deletion, I have 43 categories in cat_categories: |select count(1) from cat_categories; | count |------- | 43 |(1 row) After the deletion, I have 42 categories. |select category_id, name, default_ancestors |from cat_categories |where name = 'Education'; | | category_id | name | default_ancestors |-------------+------+------------------- |(0 rows) The children of "Education" have been correctly unmapped: |select | cccm.category_id, related_category_id, cc.name as related_name |from | cat_category_category_map cccm |inner join | cat_categories cc on (cccm.related_category_id = cc.category_id) |where | cccm.category_id = 100; | | category_id | related_category_id | related_name |-------------+---------------------+-------------- |(0 rows) However, the "default_ancestors" column of the three ex-children of "Education" has _not_ been updated: |select category_id, name, default_ancestors |from cat_categories |where default_ancestors like '61/100/%'; | | category_id | name | default_ancestors |-------------+-------------+------------------- | 101 | Arts | 61/100/101/ | 102 | School Time | 61/100/102/ | 103 | Literacy | 61/100/103/ |(3 rows) The correct value of "default_ancestors" for all of the three categories should be '101/', since none of them has ancestors any more.
As I pointed out in bullet item 2 of bug 109718, comment #19, one possible way to fix this bug is to make HierarchyDenormalization aware of the "ascendants" of the instance to which HD is attached. This would probably solve both the case of CAT_CATEGORIES.DEFAULT_ANCESTORS described in this ticket and the case of CMS_ITEMS.ANCESTORS described in 109718. The problem with the current implementation of HD is that it only keeps track of the Category (or ContentItem, as the case may be) to which it is attached. It should also be responsible for notifying the ascendants of all the relevant changes made to their ancestor node.
For consistency, something similar to change 41195 should also be coded up for cat_categories.default_ancestors and site_nodes.url. Category.java and SiteNode.java should no longer depend on com.arsdigita.util.HierarchyDenormalization. The latter should be deleted. See bug 109718, comment #23.
slate