Or at least have it only replicate one-way - from the server down to the local replica so it gets updated properly.

similar to Bruce's suggestion - force the creation of a new replica from the server, over-writing the existing local replica

That might be offered as a button in a dialog if it is a foreground replication involving a client. Background replication or server-to-server replication should probably just report an error. Many reasons for this such as the database may be extremely large, there may be data in the isolated replica that is needed, or even just deciding which replica is the winner. I expect this feature would actually take a lot of effort in the details of implementation.

New 8.5.3 PIRC (purge interval replication control) does NOT fix the problem as does this idea! Or should I say PIRC is easily foiled.

As I understand it, PIRC uses the database cutoff date and won't accept any notes (including deletion stubs) with a modified date (?) older than the cutoff date. So far so good.

But let's say I have an old replica of a database that has not been replicated a really long time with the server replica (more days than the purge date). I have even forgotten that it is a replica of something "real" on the server". I play around a bit...edit a document, which updates its modified date. Just so happens I do that today, right before I finally replicate with the server. Or I run an agent that modifies any field on a number of documents, resetting their modified dates. But as you guessed, some of these same documents had been deleted on the server copy and enough time has passed such that their deletion stubs were purged.

Because I did my edits/agent after the purge date, the server will accept my changes even with PIRC enabled. Documents that were deleted in the server copy will be readded from my replica. Right? So having PIRC enabled didn't really help.

This all assumes of course that I am the Author of the docs or am Editor+ in the server database and no replication settings are blocking my updates.

For sake of argument the edits I made were things that should not be added back to the server replica. So the normal, usually good behavior in which edits supercede a deletion, doesn't apply here.

I agree with this idea, to first check the replication history of the sending database and if the last replication was older than the target server database cutoff date not allow replication. And also not allow replication if the sending database history has been cleared. This would disqualify the sending database completely. Then have some admin override capability to allow replication and reset the history. Then do the PIRC test on document level.

I have not yet had a chance to explore it. But the nice thing is if it doesn't work as intended, then you can now file an SPR and it will be addressed as a bug rather than a feature enhancement.

Yep. Looks like they missed the mark here. It should block ALL replication if no replication has occurred within the purge interval. Call IBM support and let them know.

Here is how the feature is described in the "What's new in 8.5.3":
A new replication option, Enable Purge Interval Replication Control, on the Space Savers tab, prevents older deletion stubs and document modifications from replicating to an application.

For the record, this is a different problem than PIRC addresses (and which has been brought up at Lotusphere and all manner of contact forever). The idea here would effectively break normal replication (change a document - updating its modified time - and it gets replicated). The problem PIRC addresses involves the case where there are NO changes but documents present in a restored replica (say) that no longer have deletion stubs to keep them out of another replica.

There are easily as many people who would want new changes to replicate - period - as those who want them to be governed by some date rule.

So "they missed the mark" - don't think so. Not per all the feedback we've gathered.

This is a different mark and one you should champion if you think it's commonplace and important. We can certainly implement it also .. doesn't sound too hard.

John Curtis - IBM Senior Technical Staff Member, Domino Development