Hey, So, continuing with the ideas from my Git post: If a system, let's say PetStore, uses the Git model, where a "client" and a "server" really are equally important, then a Vet using PetStore that needs to do a housecall will want to do a "checkout" of relevant data before going to the Owner to treat the Pets. What data should be downloaded? This is determined by Aggregates, which are defined in the domain model. The Vet indicates the Owner, and the Owner has a number of Pets, each having a Medical History, so all that data is synchronized to the Vets laptop "database". In CAP terms, we have Availability of data but have sacrificed Consistency and Network partitioning, on purpose.
The Vet can now bring up that data, and update the state of the Pet and the Medical History. The laptop is not connected, so a "Save" in the client will only store the UnitOfWork changes locally. When the laptop is later connected to the server those UoW sequences should be applied to the server. But, we need to ensure that those changes do not clash with changes that others may have made. Like Git, instead of checking the version of the individual objects, we should probably check the hash value of the Aggregate, which is the Owner in this case. All state from the Owner aggregate, that is, including all of the Pets and their individual Medical Histories, is used to calculate a hash. As long as that hash is the same as that on the laptop we will know that all is well and don't have to version check individual objects in that graph, just as Git doesn't have to check individual files. If there is a change centrally, then ordinarily there would be an error saying "could not merge, discarding data" and you'd have to start all over again. That's optimistic transactions, basically. In our case we could do refresh() on all the objects that have changed, show the aggregate in a UI, and let the Vet determine if the changes he made along with the refreshed data from the central repository is ok, and then retry the UoW completion to the server. If all is well, the central repository is now synced, and can then be synced to other offices. The same merge handling can be used for those cases, or you can assume that one office will be "owning" a particular pet, and that others will be interested in looking at it (for finding patterns in diseases in Cats for example), but won't change it. All of this relates to being able to model Aggregates explicitly (to help with Network partitioning, or database partitioning), and also very much relates to being able to express business rule validation in such a way that we can synchronize data between "clients" and have the rules run to ensure that data is always locally consistent, but not necessarily the same everywhere at the same time (what Amazon calls "eventually consistent"). I have a feeling that this is big, and that this is also going to be very important in a continually connected-and-yet-disconnected world, with applications, data and devices frantically trying to cooperate using typically single-VM thinking, but where the "central repository" model "Simply doesn't work"(tm). What say ye? Does this line of reasoning make sense? And, who wants to write an EntityStore backed by Git? :-) /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
