Deleting an item in a view with item.delete() can cause a merge conflict when
the view is later refreshed - for example, during commit - and the item was
changed in another view before this view could commit the deletion.
This conflict is apparently a common problem when sharing calendars that
contain recurrences. I added support for deferring item deletes until the view
was refreshed during commit().
When view.deferDelete() is called any subsequent calls to item.delete() don't
actually delete the item nor remove any of its values but instead:
- call item.onItemDelete(view, True), the second argument meaning the item
is being deleted with deferment.
- mark it DEFERRED such that item.isDeferred() returns True.
item.isDeleted() returns False until the item is actually deleted
later during commit()
- add it to a list of deferred-delete items on the view.
When view.commit() is called it effectively deletes the deferred items
immediately after it refreshes to the latest repo version before actually
comitting changes. Once commit() is complete, the view is no longer deferring
deletes until view.deferDelete() is called again.
Deferred deletes may be effected before view.commit() by calling
view.effectDelete(). The view is then no longer deferring deletes until
view.deferDelete() is called again.
Deferred deletes may be annuled via view.cancelDelete() or via view.cancel()
which cancels all changes made since the last commit. Again, the view is then
no longer deferring deletes until view.deferDelete() is called again.
Because a deferred delete doesn't really delete anything until later, code
that depends on the item being immediately deleted by, for example, depending
on the fact that the item lost all its values, including bi-refs to other
items, needs to reconsider this assumption. The onItemDelete(view, deferred)
hook is a good place to enforce such assumptions by removing some values that
need to be removed right away.
Yes, this is hairy but it looks like that deferred delete is actually a much
safer way to operate by default. Because making this the default is quite a
big API change, I felt it was a little too close to the alpha 2 freeze date
to make it so. If this proves to work well it is likely to become the default
during alpha 3.
Questions ? please ask.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
