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.