Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1 Random sync order of collections in a batch sync operation

open
nobody
None
8
2011-05-20
2011-05-20
Anonymous
No

While doing a sync of a hierarchy of DataCollections, the order by which collections (root collection and child collections of modified objects) are synced is random by default. The problem is with the way the rankings, set in the FXOneToMany annotations, are taken into account. By default, all the rankings are 0, so the process goes like this:

1. The root collection creates a BatchService and registeres itself with priority 0.
2. In a recursive function registerWithChildren, child collections get added with priority: parentPriority * 100 + childRanking. So if both parentPriority and childRanking are 0 (the default), all collections get registered with priority 0.

Probably the easiest fix would be to change the root collection's priority to 1.

Also, why doesn't the delete order also take rankings into account? The formula for the priority of deleted objects' child collections is parentPriority + 1.

Also, note that there's a bug in the documentation of FXOneToMany: it says that the formula for the priority of child collections is parentPriority + 100 + childRanking.

Discussion


  • Anonymous
    2011-05-20

    • priority: 5 --> 8
     
  • Filip,
    Yes, leaving ranking unassigned results in children (of the same level) being processed in the unpredicted order. On the other hand, if you set the rankings (using @FXOneToMany) of two children as 0 and 1, correspondingly, the formula will evaluate 0*100 + 0=0 and 0*100+1=1. The first child will have higher priority (0), the second - lower (1). Please let me know if my answer clarifies the issue.
    Victor

     

  • Anonymous
    2011-08-26

    Sorry for the delay.

    Perhaps I wasn't clear enough. What I'm trying to say is that not only children on the same level (horizontally) get processed in the unpredicted order, but that also happens vertically, at least in the case of modified objects (the delete order doesn't take rankings into account). The reason is that BatchService internally assigns priority to each collection and then sorts them based on this priority. But the assigned priority of each collection is always 0! (If all rankings are 0, the default.) So the sort, as it is not stable, sometimes puts the child collection in front of the parent collection. (Functions I'm talking about are batchRegisteredCollections and registerWithChildren, and the array is __registry.)

    I hope you now see what's going on. The problem would go away if the root DataCollection would register itself with priority 1 in the sync function. But maybe it's not the best solution, as the processing order should be correct no matter which priority the root collection chooses. So maybe the formula should be (parentPriority+1)*100+childRanking.