Details
-
Bug
-
Resolution: Cannot Reproduce
-
Major
-
None
-
3.0
-
Unknown
-
N/A
-
N/A
-
Description
This problem is essentially XWIKI-299 reincarnated.
A ListProperty may exist in any of 3 tables. It may take the form of a DBListProperty (xwikilists), a ListProperty (xwikilergestrings), or a StringProperty (xwikistrings).
public BaseProperty newProperty() { BaseProperty lprop; if (isRelationalStorage() && isMultiSelect()) { lprop = new DBStringListProperty(); } else if (isMultiSelect()) { lprop = new StringListProperty(); } else { lprop = new StringProperty(); } return lprop; }
Changing the multi-select or relational attributes causes the location of the list to change and when the class is next saved, Hibernate panics because there is already a value in a different <joined-subclass>.
The patch for XWIKI-299 modified all of the objects if the class when the class was modified so that when they were next loaded they would be correct. The patch for XWIKI-299 does not work if an object is saved using the old class after the new class is saved.
Because of XWIKI-6170, it is possible to end up loading an old version after a new version of a document is saved. If one loads the old version of the class and uses that to create and save an object, the object property will be stored in the wrong table and the patch for XWIKI-299 will not fix it until the class is saved again.
Attachments
Issue Links
- relates to
-
XWIKI-11800 Cannot change a list property from multiple select to single select if there is an instance that has no value selected
- Closed