microstream-one
Inconsistent Use of Refactoring Mapping
The user-defineable refactoring mapping is intended to specify new identifiers for types, fields, constants for vanished old ones (e.g. because of type renaming). However, it can currently also be used to map constant fields of a still existing class to compatible constant fields of another class. This causes resolving conflicts that lead to the conflicint root entries being discarded by the root resolving logic.
Such a use has not been covered, yet, by the design of the refactoring possibilities. It has to be decided if such an "existing -> existing" mapping shall be possible/allowed at all or if the mapping has to be validated to prevent such a use.
The current state of the processinglogic behind the refactoring mapping almost forces the following approach: 1.) Currently, such a mapping must be disallowed by recognizing it and throwing an exception. 2.) It should be discussed and decided if a "existing -> existing" mapping capability shall be introduced as an additional feature in the future, including the processing logic required to handle it correctly.
Currently, without recognizing and forbidding such a use, it can cause the the problem described in microstream-one/microstream-public#10. However, and appropriate fix for microstream-one/microstream-public#10 will prevent that.
But there can still be inconsistent behavior: Seemingly registered constants are discarded from the root resolving and are afterwards re-registered, but with new objectIds. All implicitely and only traceable after intensive bug hunting research.
Some thinking brought the conclusion that such invalid cases cannot be recognized, because they moreless "do not exist".
It is perfectly valid that some constant field (and the instance identified by it) moves from one existing class to another within the scope of some refactoring. It is even perfectly valid that the source class then gets a business-logically new constant field with a new instance but with the same type and even the same name as the old (moved) constant field. So the behavior "constant field gets mapped to another class but is still kept being registered, but with a new OID" is perfectly fine. Or "can be", at the user's responsibility.
Maybe the problematic case is rather mapping a constant to the same identifier of an already registered constant, effectively displacing and discarding that one (or the one to be moved?)
Requires some more thinking ...