In specific cases, consuming a snapshot with sequence number n and the subsequent fragments (n+1,.., n+m) leads to different foreign data in the MIDB than consuming the snapshot n+m. Clarification: this occurs when fragments do not hold all information about the entity that has been updated. E.g. consider Doc1 and Doc2 associated with Service1 by the relation NeedDoc (see the MIDB data model). So we have the two triples Service1- needdoc-Doc1 and Service2-needdoc -Doc2. Suppose we update a Doc3 which is not associated with Service1, but we want to make this association. We can do this using Transformation module, like Doc3.setNeedDocs([Service1 needdoc Doc3]). At this moment Doc3 is updated, Service1 is also updated and will contain only the needdoc(Service1 and Doc3). However, the fragment will contain only data about the Doc3 and not info on the new associations between Service1 and Doc3. So when aggregating, the Doc3 will updated but not Service1, so the foreign data will still have the two old triples Service1 needdoc Doc1 and Service1 needdoc Doc2. So, if in the next sequence we obsolete Doc1 (we can do that because is nothing depends on it), the aggregation will fail because of the constraints. To avoid this perhaps the recommendation would be to call update on associations from top entities (use Service.setNeedDoc instead of Doc.setNeedDoc, use Service.setSagency instead of Org.setSagencies, etc).
SYN-48 Possible inconsistencies when aggregating fragmentsPermalink
Published on: 18/12/2012
Login or create an account to comment.