You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Cheong Chung Onn <ch...@greenfossil.com> on 2009/01/25 04:53:20 UTC
What is ModifyTimestamp operation attribute expected behavior?
Hi Emmanuel and All,
We discovered this hidden feature of ApacheDS which we thought is ultra
cool but it works only under a certain condition which we yet to determine.
Here's the scenario. We have a containing(parent) entry which has 2
attributes whose syntaxes are DN (1.3.6.1.4.1.1466.115.121.1.12). These
2 attributes in turn are holding the DN some other entries as shown below.
Parent
=========== ==========
| Attr A | --> | Entry A|
| | ==========
| | ==========
| Attr B | --> | Entry B|
=========== ==========
When we modify Entry A, its "modifyTimestamp" changed as expected,
however what is interesting is the containing/parent entry's
"modifyTimestamp" attribute is also changed. If this is is an expected
behavior of apacheDS then it is ultra cool, is the a hidden feature?
However, if we modify Entry B, its "modifyTimestamp" also changed as
expected, but the containing entry's "modifyTimestamp" remains unchanged
though.
Btw - ObjectClass is indexed in this partition :-)
This leads me to ask another question pertaining to alias. Will an alias
entry "modifyTimestamp" get updated when its referenced entry is modified?
Regards,
chung-onn
Re: What is ModifyTimestamp operation attribute expected behavior?
Posted by Cheong Chung Onn <ch...@greenfossil.com>.
Hi Kiran,
Kiran Ayyagari wrote:
>
>
> Cheong Chung Onn wrote:
>> Hi Emmanuel and All,
>>
>> We discovered this hidden feature of ApacheDS which we thought is
>> ultra cool but it works only under a certain condition which we yet
>> to determine.
>>
>> Here's the scenario. We have a containing(parent) entry which has 2
>> attributes whose syntaxes are DN (1.3.6.1.4.1.1466.115.121.1.12).
>> These 2 attributes in turn are holding the DN some other entries as
>> shown below.
>>
>> Parent =========== ==========
>> | Attr A | --> | Entry A|
>> | | ==========
>> | | ==========
>> | Attr B | --> | Entry B|
>> =========== ==========
>>
>> When we modify Entry A, its "modifyTimestamp" changed as expected,
>> however what is interesting is the containing/parent entry's
>> "modifyTimestamp" attribute is also changed. If this is is an
>> expected behavior of apacheDS then it is ultra cool, is the a hidden
>> feature?
>>
>
> it is the expected behavior
Is this expected behavior part of Ldap Specs? Or it is just ApacheDS
implementation?
If I have a multi-generation of entries e.g. Grand-Parent, Parent,
Child, will the Grand-Parent "modifyTimestamp" attribute also be changed
when the Child's attributes is modified?
Re: What is ModifyTimestamp operation attribute expected behavior?
Posted by Kiran Ayyagari <ay...@gmail.com>.
Cheong Chung Onn wrote:
> Hi Emmanuel and All,
>
> We discovered this hidden feature of ApacheDS which we thought is ultra
> cool but it works only under a certain condition which we yet to determine.
>
> Here's the scenario. We have a containing(parent) entry which has 2
> attributes whose syntaxes are DN (1.3.6.1.4.1.1466.115.121.1.12). These
> 2 attributes in turn are holding the DN some other entries as shown below.
>
> Parent =========== ==========
> | Attr A | --> | Entry A|
> | | ==========
> | | ==========
> | Attr B | --> | Entry B|
> =========== ==========
>
> When we modify Entry A, its "modifyTimestamp" changed as expected,
> however what is interesting is the containing/parent entry's
> "modifyTimestamp" attribute is also changed. If this is is an expected
> behavior of apacheDS then it is ultra cool, is the a hidden feature?
>
it is the expected behavior
> However, if we modify Entry B, its "modifyTimestamp" also changed as
> expected, but the containing entry's "modifyTimestamp" remains unchanged
> though.
>
> Btw - ObjectClass is indexed in this partition :-)
>
> This leads me to ask another question pertaining to alias. Will an alias
> entry "modifyTimestamp" get updated when its referenced entry is modified?
No
>
> Regards,
> chung-onn
>
--
Kiran Ayyagari