Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: mail@stefan-seelmann.de
In-Reply-To: <4CD2B379.7030401@gmail.com>
References: <AANLkTikTaok1=EXaVi9smS=OvTrtYGKxG2EgTxb1DGrg@mail.gmail.com>
	<4CD2B379.7030401@gmail.com>
Date: Thu, 4 Nov 2010 14:44:55 +0100
Message-ID: <AANLkTinMyn0FN345tcq5jiStt_MHasVmTeX=R4Jd_H==@mail.gmail.com>
Subject: Re: Entries in write operation contexts
From: Stefan Seelmann <seelmann@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: text/plain; charset=UTF-8

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.


Kind Regards,
Stefan