4.6. Modify Operation The Modify Operation allows a client to request that a modification of an entry be performed on its behalf by a server. The Modify Request is defined as follows: ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, modification SEQUENCE OF SEQUENCE { operation ENUMERATED { add (0), delete (1), replace (2) }, modification AttributeTypeAndValues } } AttributeTypeAndValues ::= SEQUENCE { type AttributeDescription, vals SET OF AttributeValue } Parameters of the Modify Request are: - object: The object to be modified. The value of this field contains the Dn of the entry to be modified. The server will not perform any alias dereferencing in determining the object to be modified. - modification: A list of modifications to be performed on the entry. The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. 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. The values that may be taken on by the 'operation' field in each modification construct have the following semantics respectively: add: add values listed to the given attribute, creating the attribute if necessary; delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion; replace: replace all existing values of the given attribute with the new values listed, creating the attribute if it did not already exist. A replace with no value will delete the entire attribute if it exists, and is ignored if the attribute does not exist. Notice that we tried to leverage as much as we already can from the JNDI. Both the Names and ModificationItems are used here to make the API as easy as possible to understand. We do not attempt here to write a JNDI provider which losses the explicit request type usage that we are looking for. Also note that this library is both for the client side as well as the server side unlike the JNDI which is strictly for the client side. From the JNDI we borrow good ideas and familiar signatures, interfaces and classes where we can.
@author Apache Directory Project
4.6. Modify Operation The Modify Operation allows a client to request that a modification of an entry be performed on its behalf by a server. The Modify Request is defined as follows: ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, modification SEQUENCE OF SEQUENCE { operation ENUMERATED { add (0), delete (1), replace (2) }, modification AttributeTypeAndValues } } AttributeTypeAndValues ::= SEQUENCE { type AttributeDescription, vals SET OF AttributeValue } Parameters of the Modify Request are: - object: The object to be modified. The value of this field contains the Dn of the entry to be modified. The server will not perform any alias dereferencing in determining the object to be modified. - modification: A list of modifications to be performed on the entry. The entire list of entry modifications MUST be performed in the order they are listed, as a single atomic operation. 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. The values that may be taken on by the 'operation' field in each modification construct have the following semantics respectively: add: add values listed to the given attribute, creating the attribute if necessary; delete: delete values listed from the given attribute, removing the entire attribute if no values are listed, or if all current values of the attribute are listed for deletion; replace: replace all existing values of the given attribute with the new values listed, creating the attribute if it did not already exist. A replace with no value will delete the entire attribute if it exists, and is ignored if the attribute does not exist. Notice that we tried to leverage as much as we already can from the JNDI. Both the Names and ModificationItems are used here to make the API as easy as possible to understand. We do not attempt here to write a JNDI provider which losses the explicit request type usage that we are looking for. Also note that this library is both for the client side as well as the server side unlike the JNDI which is strictly for the client side. From the JNDI we borrow good ideas and familiar signatures, interfaces and classes where we can.
@author Apache Directory Project
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |