Evgeniy Kosov wrote:
Hi there,
First of all, I'm new to this list, so, please, forgive me if this is a wrong place for the questions below, and feel free to redirect me wherever is more appropriate.
The issue I'm facing as stated above is regarding the syncrepl and attribute order. I'm writing a Perl module to be used with back_perl and noticed behaviour that seems strange. Making some modifications on the master server (provider) and looking on the relevant modifications on the slave I saw that they didn't quite match. There were some extra REPLACE operations made by syncrepl. Later investigation showed that the cause of those REPLACE's was different attribute order on the master and slave nodes. synrepl.c says that:
/* We assume that attributes are saved in the same order * in the remote and local databases. So if we walk through * the attributeDescriptions one by one they should match in * lock step. If not, look for an add or delete. */
Which seems strange to me. As a result syncrepl makes a REPLACE for every attribute whuch is "misplaced" in the local object.
This is probably not an issue if master and slave both use the same back-end module. Which is not true in my case.
So, the questions are:
Is that replacing of "misplaced" attributes by syncrepl is expected behaviour or just a side effect of its syncrepl_diff_entry diff'ing algorithm?
Yes.
Does attribute order matter? Is it specified somehow (sorted by modification time?)?
No, attribute order in LDAP is unspecified.
Should this issue be reported as bug?
No. It is clearly working as designed.