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

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

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

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.


Ing. Pierangelo Masarati
Responsabile Open Solution

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it