To Do in buildxml.plugins.portal.SyncPlugin_portal._consolidate
- This can be serious: If an object in the portal reports a wrong
modification date, this could lead to this case. Object A is not
existant when the first run is initialized. On the second run, object A
exists, but reports a modification date earlier than that of the first
run, so it is sent as a stub, although the data of A has never been
indexed before! If a entry is modified during the update and has
already been acquired as beeing unmodified, there is a slim chance,
that the entry appears as both, modified and as a stub. If a entry is
deleted during the update there is a chance of receiving a duplicate or
missing an entry. Also, this case could happen, if the modification
date is not used properly in
remoteSyncQueryXML -
investigate! This could be solved by discarding incomplete entries,
issuing a warning about this with full url of the entry and doing a
full run every week or so... Or, collect all urls of the false stub
entries and request them afterwards one by one. Would require changes
in remoteSyncQueryXML. Second option sounds best... This
has no priority at the moment, since the chances for this to
occurr are very slim.
|