Hi!
I had an idea for a new feature of slapcat (maybe ldapsearch, too), but I don't know where to file such. So I'm presenting the idea here:
"Diff-friendly output format" The order of LDAP attributes is not determined, so after a change to an entry the order of attributes may vary. If you diff the older with the current output, there are more differences than actually there were changes.
For example consider this diff (partial output): +entryCSN: 20250319115404.360112Z#000000#005#000000 +modifiersName: cn=config +modifyTimestamp: 20250319115404Z contextCSN: 20130722065709.189194Z#000000#000#000000 contextCSN: 20241204070658.632888Z#000000#001#000000 contextCSN: 20200721123717.002866Z#000000#002#000000 contextCSN: 20181031083258.073732Z#000000#003#000000 -contextCSN: 20250319114038.822575Z#000000#005#000000 +contextCSN: 20250319140809.186543Z#000000#005#000000 contextCSN: 20250227092006.790591Z#000000#006#000000 -entryCSN: 20250319115404.360112Z#000000#005#000000 -modifiersName: cn=config -modifyTimestamp: 20250319115404Z
The modifiersName did not change, but its position had moved in output. In a diff-friendly format the position would not change. Obviously that could be done by sorting the output by attribute names (which would also help to locate a specific attribute), but it would have performance impacts, obviously.
Another related option is attributes with a list of sub-attributes (name-value pairs), like syncrepl: In standard format the lines are wrapped, and with "-o ldif-wrap=no" you get one long line. For diff-friendliness may idea was to optionally wrap such name-value pairs after each pair, and if a single one exceeds the standard lengh, it would be wrapped still.
So the idea could be like this:
Use option -D for diff-friendly output format (sorting of attributes), and when doubled, also enable wrapping of name-value pairs. With "-o ldif-wrap=no" given also, single name-value pairs would end up on a separate line, but such lines wouldn't be wrapped themselves. Alternatively one could use "-odiff-friendly=X" where X is 1 or 2. (In case of contextCSN one could even think of X=3 activating sort of the same attribute by attribute value)
Do you think it's a useful enhancement? I must admit I played with the idea implementing it myself, but after having had a look at the source of slapcat, it looked more low-level than I had expected, so I had no idea where to start...
Kind regards, Ulrich Windl
On Thu, Mar 20, 2025 at 08:08:34 +0000, Windl, Ulrich wrote:
The modifiersName did not change, but its position had moved in output. In a diff-friendly format the position would not change. Obviously that could be done by sorting the output by attribute names (which would also help to locate a specific attribute), but it would have performance impacts, obviously.
I agree that some kind of "normalized" LDIF output format would be useful.
Not just for diffing, but also for storing LDIF objects, or entire trees, (including for example cn=config) in a version control system.
Geert
On Thu, Mar 20, 2025 at 08:08:34AM +0000, Windl, Ulrich wrote:
I had an idea for a new feature of slapcat (maybe ldapsearch, too), but I don't know where to file such.
"Diff-friendly output format"
The modifiersName did not change, but its position had moved in output. In a diff-friendly format the position would not change. Obviously that could be done by sorting the output by attribute names (which would also help to locate a specific attribute), but it would have performance impacts, obviously.
Another related option is attributes with a list of sub-attributes (name-value pairs), like syncrepl: In standard format the lines are wrapped, and with "-o ldif-wrap=no" you get one long line. For diff-friendliness may idea was to optionally wrap such name-value pairs after each pair, and if a single one exceeds the standard lengh, it would be wrapped still.
Do you think it's a useful enhancement? I must admit I played with the idea implementing it myself, but after having had a look at the source of slapcat, it looked more low-level than I had expected, so I had no idea where to start...
Hi Ulrich, the test suite needs it already, so there's a tool that does what I think you're suggesting in tests/progs: https://git.openldap.org/openldap/openldap/-/blob/master/tests/progs/ldif-fi...
Regards,
openldap-technical@openldap.org
-
Geert Hendrickx -
Ondřej Kuzník -
Windl, Ulrich