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, Stefan
