When running my LDIF contains a delete modification for a attribute mhsDLMembers. The information is then added new with the mhsDLMembers;binary:: <Base64EncodedData>
Apparently our customer generates all LDIF files where an entry that contains this mhsDLMembers attribute will always be added using mhsDLMembers;binary::
Before I merge the modification into server I check for the availablility of the attribute, so I can warn the user that before the merege the attribute did not exist.
So far in my testing this works just fine when testing against a simulated production server. However, when I load the base directory structure into the InMemoryDirectoryServer via the LDIF and try to check an entry for the attribute's existance it comes back null. This is because it cannot find the attribute name mhsDLMembers. However, if I change my delete modification to delete the attribute mhsDLMembers;binary it seems to work just fine.
I know that we had some similar problem with reading the LDIF values before, could this also be some similar case in the InMemoryDirectoryServer?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The in-memory directory server does not provide complete support for the binary encoding option as described in RFC 4522. In particular, it does not have any logic that will permit it to treat an attribute description without the binary option as equivalent to the same attribute description but with the binary option. I consider this more a lack of a feature than a bug, and is not something that I'm in a position to address for at least a couple of weeks.
As a workaround, when attempting to modify an attribute of an entry read from the server, your application should always use the exact attribute description contained in the entry that was retrieved. Alternately, if you know that the attribute is always added with the binary option, then have your client always reference it with the binary option.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
When running my LDIF contains a delete modification for a attribute mhsDLMembers. The information is then added new with the mhsDLMembers;binary:: <Base64EncodedData>
Apparently our customer generates all LDIF files where an entry that contains this mhsDLMembers attribute will always be added using mhsDLMembers;binary::
Before I merge the modification into server I check for the availablility of the attribute, so I can warn the user that before the merege the attribute did not exist.
So far in my testing this works just fine when testing against a simulated production server. However, when I load the base directory structure into the InMemoryDirectoryServer via the LDIF and try to check an entry for the attribute's existance it comes back null. This is because it cannot find the attribute name mhsDLMembers. However, if I change my delete modification to delete the attribute mhsDLMembers;binary it seems to work just fine.
I know that we had some similar problem with reading the LDIF values before, could this also be some similar case in the InMemoryDirectoryServer?
The in-memory directory server does not provide complete support for the binary encoding option as described in RFC 4522. In particular, it does not have any logic that will permit it to treat an attribute description without the binary option as equivalent to the same attribute description but with the binary option. I consider this more a lack of a feature than a bug, and is not something that I'm in a position to address for at least a couple of weeks.
As a workaround, when attempting to modify an attribute of an entry read from the server, your application should always use the exact attribute description contained in the entry that was retrieved. Alternately, if you know that the attribute is always added with the binary option, then have your client always reference it with the binary option.