I just smacked into this myself. I don't know that I'm going to get a PR for it for a while, but here's my notes in case someone else finds them.

add/delete/modrdn operations are being dropped on the floor (# Consume the unhandled change record == NOOP). The modify operations from a mixed LDIF of changes are being put in .all_modify_changes with no mention that it's changetype==modify (because only modify operations go in there, so it's implied modify-only and mentioning it would be redundant). But if an LDIF is 3 changes like delete then add then modify, we can't reasonably parse that into 3 separate lists (because LDIF-order matters), and we can't change the structure of .all_modify_changeswithout a major version / breaking change.

Feels like the parsed data structure is going to need to change to include the CHANGE_TYPES as part of each entry in the parser output. Like, add a new attribute on LDIFRecordList on the order of .all_changes to record all change records, that looks "just like" the current entries, except we specify the change type explicitly. I don't know why you'd even use .all_modify_changes (other than "99% of all LDAP changes are modifies") and (IMO) that should be deprecated and removed as 'confusing and useless', but that's not really my immediate concern.

Uh oh!

parse_change_records missing support for "add", "delete" #483

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions