http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Consider a document with a memberId field. This field discriminates members in a database. The db is replicated to n members somewhere in this universe (ok on this planeet). On this level (just row filtering) filtering is not difficult. If the filter is changed for an existing client db this client db gets his db rebuilded completly. This how its works with ms merge replication. It works great. Even with expressions. Ms merge replication is identified per client on computername via an alias. If a client changes ip, it needs to be changed on the server too. This is done manually (That could be better).http://ayende.com/161251/ravendb-feature-request-analysis-filtered-replication-ain-t-what-you-looking-for#comment2http://ayende.com/161251/ravendb-feature-request-analysis-filtered-replication-ain-t-what-you-looking-for#comment2Mon, 11 Mar 2013 19:58:48 GMTThe occasionally connected system problem requires a completely different solution than a document database provides. You already pointed out the problems that can occur. Document databases don't give you the tools you need to solve those problems. At the crux of the issue is the fact that documents are mutable. If they weren't then this would be a much easier problem. You couldn't, for example, have disconnected updates: there could be no updates at all! To make a practical system out of immutable objects, you need a way to relate them. You need the ability to say that this object represents a change to that object. This is the other place where you end up fighting against a document database. They are not designed to be used relationally. For this kind of system, you want a historical model. This kind of model stores data as a history of related facts. A fact is an immutable record of a decision that was made in the past. By walking the relationships among facts, you can isolate a subset that a client is interested in. When the client's interests change (like they now have access to customers/6), they publish this change as a new fact. So the computation takes this into account and starts feeding them a whole new set of facts. I've documented the rules of historical modeling at http://historicalmodeling.com.http://ayende.com/161251/ravendb-feature-request-analysis-filtered-replication-ain-t-what-you-looking-for#comment1http://ayende.com/161251/ravendb-feature-request-analysis-filtered-replication-ain-t-what-you-looking-for#comment1Mon, 11 Mar 2013 12:12:34 GMT