The move operation has a limited impact if we move the AP, except if we
move an IAP. For subentries and entreeies, it's slightly more complex
+--+
|AP|
+--+
If the AP is an IAP, we have to check that the new position is valid. If
so, we can move it. Then, as the the new parent AP may have changed, we
have to modify the IAP seqNumber so that the underlying entries can be
updated later. This has to be done for all the IAP descendants too.
>>>-------------------------------------------
if AP is an IAP
then
check that the new position is valid
if the parentAP is not the same
then
get a new seqNumber
update the IAP with the new seqNumber
for each IAP in the IAP descendant do
update the IAP with the new seqNumber
done
continue down the chain
-------------------------------------------<<<
+--------+
|Subentry|
+--------+
Moving a subentry implies we update the old parentAP and the new one. Of
course, we have to check first that the changed AP are not inconsistent
after the change.
>>>-------------------------------------------
get a new seqNumber
update the old parentAP with the seqNumber (and all the IAP descendants)
update the new parentAP with the seqNumber (and all the IAP descendants)
continue down the chain
-------------------------------------------<<<
+-----+
|Entry|
+-----+
If we move en entry within the same area, we don't have anything to do
except if the entry is not up to date, and then we proceed as we do for
a search operation. Otherwise, we update the entry like if it was a add.
This has to be done for each possible roles.
>>>-------------------------------------------
for each role
get the old parentAP
get the new parentAP
if the entry is not up to date
then update the entry
done
continue down the chain
-------------------------------------------<<<
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
