Re: backend requirements for syncrepl

["Jong-Hyuk" <jongchoi@OpenLDAP.org>]

> That's my intention.  I plan to work in two directions:
> 1) provide a modification timestamp in the ldap_entries table, updated by
> triggers (high level of cooperation between the RDBMS and back-sql)
> 2) always perform a full reload (no cooperation between the RDBMS and
> back-sql).
>
> The latter is likely to be a typical scenario for most implementations,
> where no-one notifies changes nor even update the ldap_entries table,
> which, in fact, is more likely to be implemented as a view.
>
> Note that a medium level of cooperation is provided by triggers or agents
> that update table ldap_entries when new entries are created/deleted; this
> should be easy because entry creation/deletion is roughly univocal in
> back-sql's design (e.g. a specific key in a specific table must exist);
> modifications are much more subtle, because they can occur anywhere in the
> database without even being related to the main table, so a trigger/agent
> that updates the timestamp may even be impossible or non convenient.
>
> The scenario (2) is very realistic, although non-optimal.  Of course
> reloads need to be scheduled within a reasonable time distance, to relieve
> both provider and consumer from excessive workload, and tuned on the
> actual size of the db.

How about having the entryCSN as the max TIMESTAMP values of all the
relevant table rows for an entry ? At the next synchronization time, it
would be possible to send only those entries having any of the relevant
TIMESTAMP values greater than the synchronization cookie.
- Jong-Hyuk