On 09/23/2016 11:31 AM, Ludwig Krispenz wrote:
the description in the commit is now fine, but given that the choice
of LDAP_CONSTRAINT_VIOLATION is a bit arbitrary it would be good to
have a comment where it is set, explaining why this error code was used.
About which error code to choose, if you have to pick one of the
errors which will allow "keep_going" it is fine, although I think the
original choice of unwilling to perform was a better match,
operations_error or ldap_other would, in my opinion, also be good
candidates - but they are in the wrong category.
Thanks Ludwig. You are right, it is missing the comment in the code.
I added the commend and also fixed an incorrect url in the bug description
Looking at ignore_error_and_keep_going, I am wondering if this
partition in go|stop is really still correct ? maybe we should
investigate this as well.
ignore_error_and_keep_going is used on both consumer and supplier sides.
On both sides it lets the replication session continuing on "transient"
error. I wonder if there is not something wrong. I think it is fine to
continue replication on minor (syntax, duplicate values, ...) failures
but the failed update is silently skipped. Just an error is logged on
the supplier side, with a invalid statement: "Will retry later" that is
false the update will be simply skipped.
Do you think we could create a conflict entry with the op parameters
that were skipped ?
On 09/23/2016 10:08 AM, thierry bordaz wrote:
> Thanks Noriko for your review. I updated the patch to give more
> explanation why the fix is in modify_schema_dse.
> I pick up LDAP_CONSTRAINT_VIOLATION in replacement of
> UNWILLING_TO_PERFORM but I have not strong opinion on appropriate
> value of that returned value. In the logic of that fix, it just needs
> to be not fatal regarding ignore_error_and_keep_going.
> 389-devel mailing list -- 389-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-leave(a)lists.fedoraproject.org