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