[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/