directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Entries in write operation contexts
Date Thu, 04 Nov 2010 18:29:48 GMT
On 11/4/10 2:44 PM, 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
Still having some issue understanding the difference...

The modify operation should work this way :
- read the entry from the backend (originalEntry)
- add the operational ATs on the list of modifications to apply
- apply those modifications on an entry clone, which will be ditched 
when done
- in the backend, read the entry from the disk (again)
- then apply the mods on the read entry

So, yes, we read the entry twice, and we can avoid doing so if we can 
use the modified entry

For the rename operation, and the move operation, the modifications done 
on entry are lighter :
- we read the entry (original entry)
- we clone it (modifiedEntry)
- we add the OpAttrs to modifiedEntry
- in the backend, we replace the current entry with the modified entry

I think we can have the same approach for the modify operation : as it's 
already computed by the SchemaInterceptor, there is no need to do it 
again in the backend.

If this is what you are suggesting, then I'm totally +1.

>
> So my idea here is to also use the 2nd approach for the modify operation.
>
>
> Kind Regards,
> Stefan
>


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message