Pete Rowley wrote:
Ok. So I think the errors should be treated a little differently. If the search fails, that's bad - probably a fatal error, or perhaps someone deleted the configuration entry out from under you. I think that if the mod fails, you should check the error code, for something like LDAP_TYPE_OR_VALUE_EXISTS, which means the mod->add failed because attribute already has that value, or whatever specific error is returned from the mod->delete value operation when the value doesn't exist. Other errors are probably fatal.Rob Crittenden wrote:It's actually the mod operation that can fail, the original value is deleted and the new value added in one operation with two mods, if the original value has changed since the search the mod operation will fail. It's a way to get an atomic increment.Pete Rowley wrote:New pre-operation plugin:In dna_get_next_value() what could cause a call to slapi_search_internal_get_entry() to fail that you have to try 3 times?
Would it be better to use an unsigned long to represent the value or is this longer than any possible uid (the downside, or upside, being that 64-bit could support significantly larger numbers)? If so the new_value field would need to be expanded.Yes it should probably be unsigned long, I'll change that.rob ------------------------------------------------------------------------ -- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel------------------------------------------------------------------------ -- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-devel mailing list Fedora-directory-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
