On Wed, 2005-12-07 at 02:38 -0800, Howard Chu wrote:
ando@OpenLDAP.org wrote:
I'm not sure this makes sense. If you're going to generate the CSN, then there's no reason to do the search at all. I.e., assuming the server's clock hasn't been reset, the generated CSN will always be newer than anything already in the database.Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays
Modified Files: syncprov.c 1.133 -> 1.134
Log Message: rework previous commit?
CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/ http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c
Changes are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed.
Again, the original code does a search to find the greatest entryCSN in the DB. It may not be crucial to get this value for a database that has never been contacted by any consumers yet, so just generating when si_ctxcsn is empty may be fine.
My point is: the original code is searching for "(entryCSN>=)"; is this
the intended behavior? I mean: does the above filter make sense?
Because that's what gets to the underlying backend; in this case, I need
to handle it in back-sql, because it expects a non-empty value in the
AVA.
Again, feel free to revert, or to modify my commit, I'm not going to
break the correct behavior. Only, I'm not sure the current behavior, in
this exceptional case, is as intended.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/