Pete Rowley wrote:
Rob Crittenden wrote:
> 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?
>
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.
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.
> 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(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>
------------------------------------------------------------------------
--
Fedora-directory-devel mailing list
Fedora-directory-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-devel