[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: syncrepl and attribute order
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/