On 4 nov. 2010, at 14:44, Stefan Seelmann wrote: > On Thu, Nov 4, 2010 at 2:22 PM, Emmanuel Lecharny <[email protected]> wrote: >> 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 getModifedEntry() is only used by rename and move operations. > > The add and modify operations use getEntry() > >> 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 >> checked. > > Right, and that's ok. > >>> 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. > > Yes, but in the OperationContext classes there are two fields. > > >>> 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 ? > > For a modify request the modifed operational attributes are added to > the modification items. For example such a modify request > > dn: cn=someentry > changetype: modify > add: description > description: blah blub > - > > is extended by the OperationalAttributeInterceptor > > dn: cn=someentry > changetype: modify > add: description > description: blah blub > - > replace: modifyTimestamp > modifyTimestams: 19700101000000Z > - > replace: modifiersName > modifiersName: uid=admin,ou=system > - > > and in the backend the operational attributes are set to the enty > (which is loaded from the backend) and stored to the backend. So in > the backend we > - load entry from disk > - apply modifications (including operational attributes added by interceptors) > - save entry to disk > > > In contrast, for the rename and move operations there are no > modification items that can be used to set operational attributes in > the interceptor chain. Instead the clonedEntry / modifiedEntry is used > to set the operational attributes. In the backend this cloned entry is > used to apply the rename/move operation. So in the backend we > - use the entry from operation context (which includes updated > operational attributes) > - apply modifications > - save entry to disk > > > So my idea here is to also use the 2nd approach for the modify operation.
+1 Regards, Pierre-Arnaud > Kind Regards, > Stefan
