[ https://issues.jboss.org/browse/ISPN-2478?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-2478: --------------------------------------- Sorry for me to not be clear, I think I rushed this description as part of an overall design review, and the case isn't entirely clear to me either. Adrian it seems you have a test now? Let me know if you'd like some more brainstorming together about this. We mentioned this briefly on our Query triage phone call, AFAIR we said that if no better solution could be found, a valid fix (although ugly) would be to convert the put map in a sequence of simple put operations. As further consideration, this problem might be resolved at least partially by ISPN-2143 : the tricky aspect is that we need to do cleanup on indexes for the case of entries which are overwritten. An overwritten entry means that an entry could be replaced by a non-indexed type, while the removed type is indexed but potentially using a different index or different options so it's possible the the key of the two entries - while logically the same in terms of hashmap - isn't matching their indexed counterparts. I concede the problem is probably far fetched, and it feels like it takes to apply multiple bad coding practices to trigger the scenario.. this leads me to think that I would consider it acceptable if we can detect the tricky mapping (from annotations?) and log a warning about the problem, and document it as an unsupported scenario. If you have a test it would be a great help to document it, as it's quite unclear to me as well how it would behave. By bad coding practices I specifically mean that a Value is being replaced by a Value of a different type. Different types being stored under a same-typed index seems quite fishy to me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira