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).

Component

Code

Category

bug