directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: Entries in write operation contexts
Date Thu, 04 Nov 2010 17:12:29 GMT

On 4 nov. 2010, at 14:44, Stefan Seelmann wrote:

> On Thu, Nov 4, 2010 at 2:22 PM, Emmanuel Lecharny <elecharny@gmail.com> 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


Mime
View raw message