#48161 RFE: it could be nice to have replication conflicts being skipped in client app queries.
Closed: wontfix 2 years ago by mreynolds. Opened 6 years ago by gparente.

I am looging this RFE as a complement of

ticket 160:Make replication plugin put conflicts and tombstones in a special suffix

This ticket concerns only replication conflicts. Several clients are finding replication in queries like, for instance, named (component bind-dyn-ldap):


DNApr 16 18:05:02 ipaserver named[5340]: failed to convert DN
'nsuniqueid=f311d481-7ded11e3-8956f0ed-685ab636,idnsname=XXX.com
,cn=dns,dc=xxx,dc=local' to DNS name:


It could be interesting to have replication conflicts hidden as, for instance, belonging to objectclass: ldapsubentry.


it is not possible to completely hide the results of conflict resolution. If the two conflicting entries have different children, this will be reflected in their dn, independent if the conflicting entry is hidden or not.

This is the scenario:
on A add
dn: cn=user_YYY,<suffix>
dn: cn=child_Y1,cn=user_YYY,<suffix>

on B add (simultaneosly):
dn: cn=user_YYY,<suffix>
dn: cn=child_Y2,cn=user_YYY,<suffix>

NOTE: parent dn is identical, child dn is not.

After replication we have:
dn: cn=user_YYY,ou=People,dc=example,dc=com

dn: cn=child_Y1,cn=user_YYY,ou=People,dc=example,dc=com

dn: cn=user_YYY+nsuniqueid=28ad5989-13f611e5-ac309989-c3cc84f8,ou=People,dc=example,dc=com

dn: cn=child_Y2,cn=user_YYY+nsuniqueid=28ad5989-13f611e5-ac309989-c3cc84f8,ou=People,dc=example,dc=com

we could hide the conflicting entry, but not its child.

This scenario also makes the original request unfeasable, if we would put the entry into a separate backend, we would have an orphaned child

Good point, this is a problem. What about adding ldapsubentry objectclass to conflicting entries to hide them from ordinary searches?

Couldn't be the children of a conflicting entry considered also replication conflicts and logged as such ?

Metadata Update from @lkrispen:
- Issue set to the milestone: 1.3.6 backlog

4 years ago

Metadata Update from @mreynolds:
- Issue close_status updated to: None
- Issue set to the milestone: 1.4 backlog (was: 1.3.6 backlog)

4 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to None
- Issue tagged with: RFE

4 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1492

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)

a year ago

Login to comment on this ticket.

Metadata