On 8/10/05, Nicklas Lindgren <nili@...612...> wrote:
By replacing the code above with a call to sp_selection_delete_impl(), the bug is fixed, but the clones become regular duplicates.
Is this desirable? Or should it be fixed in a way that preserves clone-relations? (The comment seems to indicate that this is the plan.)
Yes, the idea was to preserve the clone links as much as possible. However I still do not understand the reason for the bug. The deleteObject (false) deletes the object without notifying its clones, so they don't get the chance to realize they are orphans. Later, that same object is restored in the pattern, with the same ID, so the clones should just stay, now linked to that restored object. This works when the clone of the object going into pattern is itself outside the pattern; what exactly breaks if it's inside?
Ah, probably what happens is that the clone that goes into the object is restored FIRST, at the time when its original is not yet restored, and thus breaks. So I think the fix should just change the order of restoring objects in the pattern, making sure all clones are restored LAST. Perhaps implementing something like sort_by_cloning(objects) would be nice (and useful in other situations too), that would take a list of objects and sort them in such a way that each original is always closer to the beginning of the list than any of its clones in the same list. Then in restoring object, you iterate over the sorted list, making sure clones are not restored before their originals.