If you're using Child_Update, I had a scenario similar to this. It had to do with code maintenance - codes don't change too much and here isn't much to them, so the solution isn't highly performant - but that's OK because the frequency of use is very low.
I did an override of Child_Update in the BLB and looped through the children setting their sort values (I believe its an internal property) to their index, and then did base.Child_Update. (which took it from there)
I don't know if that's entirely identical to what you're attempting to do, but it sounded familiar. Obviously, in the event an item is inserted into the middle, it will force an update on potentially all of the codes (if inserted at position 0) -- but like I said, since it's a low frequency event and the objects are tiny, I wasn't too worried about it.
Chris
We ran into something similar (and had hierarchy too). Someone I worked with did a performance test and found that, in our case, it was actually more performant to update the indexes as properties on each item whenever an applicable change was made to the list (add, remove, move) rather than iterate through the whole list each time we needed to re-index (on save in your case, I guess).
In our case we had long lists and, as I mentioned, a hierarchical component, and changes to the list itself were far less frequent than changes to the list items. Trust me, the logic wasn't the simplest but it did work out for us. For an incremental cost when an item was removed, inserted into the middle of the list or otherwise moved, we saved a ton not having to lookup each item's position as we iterated through to save. We basically spread it out rather than incurring it all at once.
Something to think about.
why not override the ChildUpdate and use a
for(int x=0; x< this.Count; x++) DataPortal.UpdateChild(this[x], parameters, i);
in the middle of your override. The current code in BLB UpdatChild is pretty much the same as what you used before.
I've noticed that BLB has a lot of logic for maintaining Indices and PositionMaps. It might be that calling up to the parent from the child object, as you've considered as an alternative, might be very fast.
Copyright (c) Marimer LLC