Hi devs, I'm trying to solve DIRSERVER-1579 and stumble across the various entries that exist in the operation contexts:
1) AbstractOperationContext.getOriginalEntry() That's the original entry as stored in the backend, must not be modified 2) AbstractOperationContext.getEntry() That's a clone of the original entry, or the entry of the add operation, should be used 3) AbstractChangeOperationContext.getModifiedEntry() This is used by move, moveAndRename and rename operations, but not consistently, see below. I'd suggest to get rid of that entry and use the cloned entry instead. 4) ModifyContext.getAlteredEntry() The altered entry is set by the backend and is used by interceptors *after* the modification was applied. The interceptors that modify an incoming write operation use different entries, lets take the OperationalAttributeInterceptor for example: - add: puts operational attributes to the *cloned* entry - modify: puts operational attributes to the *list of modifications* - rename: puts operational attributes to the *cloned* entry - move: puts operational attributes to the *modified* entry - moveAndRename: puts operational attributes to the *modified* entry As said above, I'd suggest to get rid of the modifiedEntry and use the clonedEntry for move and moveAndRename operations. A further idea, to make the code more consistent is to change the way how the modify operation works: Instead of adding additional modify operations to the list we can also use the cloned entry and maintain additional attributes there (operational attributes, derived keys). That's the way how rename/move/moveAndRename operations handle the change of operational attributes, why not use the same approach for the modify operation? Thoughts? Kind Regards, Stefan
