On 08/05/2009 03:45 PM, Stefan Seelmann wrote: > Martin Alderson wrote: >> 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 am currently facing similar problems when trying to modify openldap's runtime configuration: Many attributes like olcDbConfig don't have equality matching rules, therefore delete/add modifications won't work. So at least offering an option to do replace modifications instead of add/delete even on multi-valued attributes would be really useful. Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
