Re: (ITS#6406) back-ldif fails test043-delta-syncrepl

[h.b.furuseth@usit.uio.no]

Howard Chu writes:
>> With back-ndb, I imagine somthing like an SQL 'ORDER BY<reqStart or
>> entryCSN>' will do the trick, if it isn't already handled.
>
> back-ndb also orders by entryID.

Thanks, I'll note that for the test.

>> Anyway, if I have understood this correctly, this requirement needs to
>> be documented, and it looks rather fragile anyway.  Only databases
>> supporing this use of accesslog.  The admin must not slapcat the
>> accesslog, rearrange it (maybe he's looking for changes to something
>> specific), and then slapadd it back.  Not something which would happen
>> every day, but there's no reason people _wouldn't_ do it either.  LDAP
>> defines elements as unordered, after all.
> 
> I thought it was obvious; a "log" is an ordered transcript of events.
> If you rearrange the sequence of events then you invalidate it.

No, it's not obvious that the order of slapadding entires has any
influence on their order returned from search.  The LDAP spec doesn't
say so, nor man 5 slapd-bdb, nor do the syncprov or accesslog manpages
say that they need it.

Obviously *something* need to take care of ordering, but as far as
the user knows that could be accesslog or syncprov.  Actually, the
slapo-accesslog(5) suggestion to index reqStart may give a careful
reader a hint about how the ordering happens.

So anyway, syncprov needs to document that it doesn't ensure this
ordering but depends on the admin getting it right.

Long-term I'd also like some way for syncprov to catch errors if the
admin does get tings like this wrong.  E.g. let accesslog require an
attribute to be set in the log database which promises ordering.  slapd
startup would fail if the database doesn't confirm that it can honor
this flag, and slapadd of entries out of CSN order would also fail.
Unless that breaks what you say about refresh below... anyway, all that
will have to wait for RE25 or later.

-- 
Hallvard