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: [EMAIL PROTECTED] ------------------------------------------
