directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: [Studio] add is done before delete on attribute value modification
Date Wed, 05 Aug 2009 13:45:11 GMT
Martin Alderson wrote:
> It sounds like the order of the modifications shouldn't matter so this isn't really a
bug in Studio - but it would be a nice feature to be compatible with the broken servers ;)

Ok, could you please file a Jira?

> Along the same lines, I guess we should file a bug against ApacheDS since it shouldn't
be complaining either.

Yes, I'll do.

> It's interesting that studios behaviour when modifying attribute values depends on how
many values there are to begin with - I hadn't noticed that.  I wonder if it might catch people
out: perhaps a user sees studio doing a add+delete operation on a multi-valued attribute and
assumes it will always do that, then they modify a single valued attribute and rely on studio
to give an error if someone or something else has modified that value since Studio read it.
 That's perhaps so unlikely as to not be worth considering though.  Coming from the other
side, a user might be trying to replace a value of a multi-valued attribute that is constantly
being modified by something else which might get frustrating.

Yes, you are right, thanks for your insight.

One reason for the replace operation (as mentioned in my previous mail)
are must attributes. Some servers don't like the delete/add sequence.

Another reason for the replace operation are attributes without any
matching  rule (like facsimileTelephoneNumber). It is not possible to say
  delete: facsimileTelephoneNumber
  facsimileTelephoneNumber: 123
for those attributes when there is no equality matching rule.

I have done much tests with multiple kind of directory servers and the
current implementation works good. However I haven't considered the
scenario you described. A change would cause a huge impact and requires
testing with all kind of directory servers.

Kind Regards,

View raw message