Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PR - Ticket 50363 - ds-replcheck incorrectly reports error for out of order multi-valued attributes #3423

Closed
389-ds-bot opened this issue Sep 13, 2020 · 8 comments
Labels
merged Migration flag - PR pr Migration flag - PR

Comments

@389-ds-bot
Copy link

389-ds-bot commented Sep 13, 2020

Cloned from Pagure Pull-Request: https://pagure.io/389-ds-base/pull-request/50364


Bug Description:

If for some reason an entry's multi-valued attribute values are in different orders on different replicas the tool reports this as an inconsistency when it is not.

Fix Description:

For both offline & online processing sort each entry's multi-valued attribute values.

Resolves: #3422

@389-ds-bot 389-ds-bot added merged Migration flag - PR pr Migration flag - PR labels Sep 13, 2020
@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2019-05-13 03:26:04

I think this fix is okay, but curious if there is possibly a way to sort these in the lib389 tools in mapped_object or similar so we avoid this problem? Ack if you just want merge though.

@389-ds-bot
Copy link
Author

Comment from mhonek (@kenoh) at 2019-05-13 13:45:04

We could do here something like ...{k.lower(): sorted(v) for... instead of the block below, I guess. Something similar in the next added block as well, probably.

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2019-05-13 14:55:09

We could do here something like ...{k.lower(): sorted(v) for... instead of the block below, I guess. Something similar in the next added block as well, probably.

Yeah I tried: {k.lower(): v.sort() for...} but it didn't work. I don't fully understand these type of "for loops" - need to re-read that stuff :-) I'll give this a shot, thanks!

@Firstyear

I think this fix is okay, but curious if there is possibly a way to sort these in the lib389 tools in mapped_object or similar so we avoid this problem?

Well this is outside of mapped objects in this CLI tool (ds-replcheck). It calling raw search_s and getting an "Entry". And in the other case it's built from an LDIF file (no search - it's all manually built), but I might be able to use the LDIF module for that. I'll open a new ticket to refactor the tool for mapped objects, and investigate using the LDIF module.

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2019-05-13 15:55:45

rebased onto 6c805f344e511fd919c84043481ef21cd24f47fe

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2019-05-13 15:56:55

rebased onto 974c802

@389-ds-bot
Copy link
Author

Comment from mreynolds (@mreynolds389) at 2019-05-13 15:59:04

Pull-Request has been merged by mreynolds389

@389-ds-bot
Copy link
Author

Comment from firstyear (@Firstyear) at 2019-05-14 01:18:00

Cool, no problems then :) just wanted to be sure this was checked as you are more familar with this code than I am.

@389-ds-bot
Copy link
Author

Patch
50364.patch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged Migration flag - PR pr Migration flag - PR
Projects
None yet
Development

No branches or pull requests

1 participant