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

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



On Wed, 2005-12-07 at 02:57 -0800, Howard Chu wrote:
> >
> > 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.

OK, I'll look at it.

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

In the "dumb" approach I'm trying to use for back-sql, the provider does
not provide any means to store entryCSN info; it's generated "on the
fly" by some other layer starting from some other info (in this case,
it's hardwired in back-sql, but I foresee another layer that does it in
a general manner stacked in between the database and the syncprov, or,
if it gets clean enough, in syncprov itself).  As a consequence, the
"right" approach at startup consists in simply generating a contextCSN,
under the assumption this causes a full refresh of the consumers.

p.




Ing. Pierangelo Masarati
Responsabile Open Solution

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