|
[
Permlink
| « Hide
]
Emmanuel Lecharny added a comment - 18/Aug/07 04:49 AM
This is still an existing problem.
Fixed on commit revision 567238 here:
http://svn.apache.org/viewvc?view=rev&rev=567238 I'm not going to bother backport this to 1.0 unless someone wants me to. I reopen the issue, because the double modification _is_ necessary. The 'fix' had a very bad side effect, which was not exhibited because the way the operational attributes were added to the list of modified attributes was incorrect : the list was never modifed in fact...
Here is the reason why we need this double modification : - the opAttr interceptor first call the schema interceptor - the schema interceptor check for every modification, and if the modified attr is not modifable by user (and this is the case for modifiersName and modifyTimestamp), it generates an error - as the opAttr interceptor was not correctly injecting those two attrs into the modification list, it worked well, except that we lost those modifications - and at the end, the second modification was here to store those operational attribute directly into the nexus. What was bad about this double modification (and still is) is that we cannot guarantee that the operation is atomic( we have 2 mods in a row for the same entry). Even from the perf perspective, it's far from being perect. Now the problem is that we have no easy way to add the 2 opAttrs before calling the schema interceptor, because those attrs will be seen as invalid, and it will generate an error. One possible solution would be to add a flag in the ModificationItem structure to signal an attribute which has been added by the server. The modification has been reverted in bigBang branch :
http://svn.apache.org/viewvc?rev=581856&view=rev http://svn.apache.org/viewvc?rev=581857&view=rev http://svn.apache.org/viewvc?rev=581861&view=rev Still present in trunk...
We can't affect a bug to a released version ! Rescheduled to 1.5.2
I just wonder why an operationnal attribute is checked against the schema ??? This sounds like a nonsense, as Op attr are managed by the server itself, so they are just always valid !
modifiersName and modifyTimestamp Operational Attributes are NO-USER-MODIFICATION attributes, so they should not be ruled out by the schema interceptor.
The big issue we have is that the ChangeLog interceptor is trying to revert the modification, and this include modification of operational attributes which have been added in the second pass.
IMO, we should create a second class of attributes : those who have been added by the server, w<hich shoul dbypass the Schema Interceptor. It falls into the 'Optimization' phase. Postponed to 1.5.9
Affected to 2.0.0-RC1, we won't release a 1.5.9
Fixed in schema refactoring branch, as a side fix.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Major
Double modification on a modify ?
