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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
