directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Seelmann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRSTUDIO-513) Do delete before add when modifying attribute values
Date Fri, 21 Aug 2009 15:54:15 GMT

    [ https://issues.apache.org/jira/browse/DIRSTUDIO-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746027#action_12746027
] 

Stefan Seelmann commented on DIRSTUDIO-513:
-------------------------------------------

The current behaviour is as follows:
- modification of an existing value of an single-valued attribute: replace mod
- modification of an existing value of an multi-valued attribute: add+delete mod
- additon of a value: add mod 
- deletion of a value: delete mod

So currently the schema isn't considered for attribute modifications.

For servers that provide a good schema it would be best to consider the schema:
- if an equality matching rule exists for the attribute: 
  - modification of an existing value (mv or sv): add+delete mod or delete+add mod
  - additon of a value: add mod 
  - deletion of a value: delete mod
- if no equality matching rule exists for the attribute: always use replace mod 

For servers that provide a less good schema we should allow a manual configuration.

So I would suggest that we add the following configuration parameters for each connection
(not to the global preferences as it is depends on the server):
- Checkbox: "Use schema to determine operations for attribute modification" (with the description
above in the tooltip)
This checkbox is checked by default. If unchecked the following settings become enabled:
- modification of an existing value of an single-valued attribute: [add+delete mod|delete+add
mod|replace mod]
- modification of an existing value of an multi-valued attribute: [add+delete mod|delete+add
mod|replace mod]
- additon of a value: selectbox: [add mod|replace mod]
- deletion of a value: [delete mod|replace mod]
Note: [value1|value2|value3] are drop-down boxes with one selectable value.

I hope that meets all your requrirements.


PS: Sure, it would be possible to always use replace. However when editing groups with tons
of members then for each modification all members would be transfered over the wire. So I
would suggest to keep the add and delete modification. But feel free to convince me.

PPS: The ultimate solution would be to define an extension point and to add one plugin for
each server type the controls the modification operation. But then we would have one driver
for each directory server implementation like it is the case for databases. I thought LDAP
is an implementation independent protocol...


> Do delete before add when modifying attribute values
> ----------------------------------------------------
>
>                 Key: DIRSTUDIO-513
>                 URL: https://issues.apache.org/jira/browse/DIRSTUDIO-513
>             Project: Directory Studio
>          Issue Type: Improvement
>    Affects Versions: 1.4.0
>            Reporter: Martin Alderson
>            Priority: Minor
>
> When connecting to Novell eDirectory and modifying the schema an "Attribute Or Value
Exists" error occurs.  This is due to the modification performing an add before the delete
and eDirectory (wrongly) complains that the same OID has been used more than once before realising
that the old value should be deleted.  Note that this is a problem with eDirectory but it
would be useful if Studio asked for the delete to be performed before the add when modifying
an attribute value which eDirectory is OK with.
> An example of the LDIF in the modifications logs view for an operation that fails is:
> dn: cn=schema
> changetype: modify
> add: objectClasses
> objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' [...new value...]
> -
> delete: objectClasses
> objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' [...old value...]
> -
> It also seems that modifying the schema on ApacheDS has the same issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message