[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: commit: ldap/servers/slapd/overlays syncprov.c

Pierangelo Masarati wrote:
On Wed, 2005-12-07 at 02:38 -0800, Howard Chu wrote:
ando@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays

Modified Files:
	syncprov.c  1.133 -> 1.134

Log Message:
rework previous commit?


Changes are generally available on cvs.openldap.org (and CVSweb)
within 30 minutes of being committed.

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.

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

I guess that a zero-length value here doesn't really make sense. We could use the root entry's entryCSN instead.

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.

Well, your patch raises the interesting question about whether to do the search at all, when the contextCSN attribute didn't already exist. I think it would be safe to generate the contextCSN and bypass the search.

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