directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Entries in write operation contexts
Date Thu, 04 Nov 2010 13:02:36 GMT
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?


Kind Regards,

View raw message