There are 2 comments.
 
 
XWiki Platform / cid:jira-generated-image-avatar-f35ab657-d280-4034-9323-61199cfc63b9 XWIKI-16331 Closed

Ghost entries are leftover in the page tree when a page with underscore in name is deleted, if another page with a similar name exists

 
View issue   ยท   Add comment
 

2 comments

 
cid:jira-generated-image-avatar-12fa96d2-b390-471f-a86a-72c2f52e2421 Anca Luca on 30/Aug/24 12:07
 

Charpentier Lucas are you sure this cannot be reproduced anymore?

from what I see in the code, the function that handles the removal of xwikispace entry is the one from https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/store/XWikiHibernateStore.java#L1272 , which ends up calling this one https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/store/XWikiHibernateStore.java#L869 for counting the children pages of a given space reference to know whether it should be cleaned up or not. The query from this last hasDocuments() function still seems fragile, I don't see any handling of special characters in the space name there, so the problem should still reproduce. Maybe the database engine on which you tested has some different behaviour wrt like wild chars?
Or maybe we fixed something in the display of the tree itself (so that the issue is no longer visible to the end user), but the underlying problem that the xwikispace table is not properly kept in sync still exists...

 
cid:jira-generated-image-avatar-12fa96d2-b390-471f-a86a-72c2f52e2421 Anca Luca on 30/Aug/24 12:08
 
[~Lucas C] are you sure this cannot be reproduced anymore?

from what I see in the code, the function that handles the removal of xwikispace entry is the one from https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/store/XWikiHibernateStore.java#L1272 , which ends up calling this one https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/store/XWikiHibernateStore.java#L869 for counting the children pages of a given space reference to know whether it should be cleaned up or not. The query from this last hasDocuments() function still seems fragile, I don't see any handling of special characters in the space name there, so the problem should still reproduce. Maybe the database engine on which you tested has some different behaviour wrt like
wild wildcard chars?
Or maybe we fixed something in the display of the tree itself (so that the issue is no longer visible to the end user), but the underlying problem that the xwikispace table is not properly kept in sync still exists...