Hi Stefan, > > 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...] > > - > > I guess you tried to run this LDIF with switched add/delete order? Just to > verify that it works.
Yeah, I tried switching the order myself and that works fine. 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 ;) Along the same lines, I guess we should file a bug against ApacheDS since it shouldn't be complaining either. 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. Thanks, Martin
