|
Let me pose some silliness and wonder at how to deal with it.
An attribute called X is of syntax integer
A modify adds the value "1#qrs#5" to X, then deletes the value "1#xyz#5" from X
The server tries to evaluate the two values being updated on X. Neither of them are integers, thus it can't use its normal compare routines to check for equality. I suppose the server could (in the event of syntax violations) fail over to using an exact octet match.
While the server is gathering up these modifications (in order to later commit them), I guess it can't hold the attribute values in a syntax-based data structure, because it can't rely on the values adhering to the syntax.
I think there's something even more ugly, but I can't think of it now...
Jim
>>> Timothy Hahn <hahnt@us.ibm.com> 9/5/03 1:25:28 PM >>> Jim, I had always interepreted this as indicating that even if "silly things" are done in some of the modificationItems, that the server shouldn't necessarily fail the modification because an "intermediate result" was not compliant to the schema definitions. Re-stated, an entry in the process of being modified (within an atomic operation) is allowed to be non-compliant to the schema, but by the end of applying all the modifications (at the end of the atomic operation) the entry MUST be schema compliant. That's how I always interpreted it. Regards, Tim Hahn Internet: hahnt@us.ibm.com Internal: Timothy Hahn/Durham/IBM@IBMUS phone: 919.224.1565 tie-line: 8/687.1565 fax: 919.224.2540
All, An issue has been raised regarding the language in 4.6: "While individual modifications may violate the directory schema, the resulting entry after the entire list of modifications is performed MUST conform to the requirements of the directory schema." While I believe most server implementors understand this to mean that while any one modification item may cause an object class violation, the entire set of modifications must be evaluated an no error returned if the net effect would not violate schema. For example, in one test it is expected that given the entry (singleValAttr is a SINGLE-VALUE attribute): dn: dc=example objectclass: x singleValAttr: val1 the following modify should not error: dn: dc=example changetype: modify add: singleValAttr singleValAttr: val2 - delete: singleValAttr singleValAttr: val1 While it's obvious that the net effect is to have a single value (val2) in singleValAttr, because the order is backward, a server doesn't like it. Other examples might include: - Deleting a distinguishe! d name v alue and re-adding the same value - Adding an attribute value of invalid syntax and then removing it. - Adding a value that would produce contraintViolation, then removing it. Regarding the statement above: I've always read this as a requirement on the data being presented to the server--that at least the resulting entry MUST conform. I haven't (until recently) thought about it as a requirement that the server allow silly things to be present in a list of modification items. What do others feel? Is there a need for clarity here? Are these kinds of tests valid indicators of standards-compliance? Jim |