Details
-
Bug
-
Resolution: Solved By
-
Major
-
None
-
12.3, 11.10.5
-
None
-
Unknown
-
N/A
-
N/A
-
Description
Apparently using $xwiki.getDocument in a script use by default the cache store, but the retrieved document internally have the hibernate store. This might lead to inconsistencies on the cache store since it's not correctly invalidated when performing refactoring operations.
Reproduction steps:
- Create a document Test.WebHome
- Execute the following script:
{{velocity}} #set($oldRef = "Test.WebHome") #set($newRef = "Target.WebHome") #set($oldDoc = $xwiki.getDocument($oldRef)) #set($targetDoc = $xwiki.getDocument($newRef)) Old doc: Is new? $oldDoc.isNew() Store: $oldDoc.getDocument().store.getClass() Target doc: Is new? $targetDoc.isNew() Store: $targetDoc.getDocument().store.getClass() XWiki Store: $xwiki.getXWiki().getStore().getClass() {{/velocity}}
Expected result:
- Everywhere the store class is displayed, it should be CacheStore
Obtained result:
- The HibernateStore is displayed for the document, but the XWiki Store is the CacheStore.
Attachments
Issue Links
- relates to
-
XWIKI-13935 Add atomic store API for document renames
- Closed