Pierangelo Masarati wrote:
On Wed, 2005-12-07 at 02:38 -0800, Howard Chu wrote:
[EMAIL PROTECTED] wrote:
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.
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
AVA.
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/
