directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Entries in write operation contexts
Date Thu, 04 Nov 2010 13:22:01 GMT
On 11/4/10 2:02 PM, Stefan Seelmann wrote:
> Hi devs,

Hi Stefan,
> 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.

So far, so good. The getModifiedEntry is important, as it's the one that 
contains the operational attributes we want to inject into the backend 
when doing a add, modify, rename or move operation.

The AlteredEntry is used in some cases, when there are some action done 
after the injection of the entry in the backend. Not sure it's really 
usefull, we could be able to use the modified entry at this point. To be 
> 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.
I think that cloned and modified entry are the same, or should be the 
same. I remember when I reviewed the operations 6 months ago, and 
improved there performance, I faced such an issue, but wasn't able to 
fix it. May be it's time for a better solution now.
> 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?
Not sure I completely get what you are suggesting. Can you provide a 
simple example on a very basic entry ?

Emmanuel L├ęcharny

View raw message