[Chandler-dev] deferring delete until commit

Bryan Stearns stearns at osafoundation.org
Wed Apr 26 07:49:40 PDT 2006

I've got a few questions... :-)

- Is it expected that Chandler will run all its repository views in 
deferDelete() mode all the time? (or just the background views?)

- When a recurrence is visible in the detail view and the user changes 
"occurs" such that that instance is doomed, what will now cause the 
detail view to stop showing that item? (I'm hoping the item watcher will 
fire and I can ask isDeferred() the way I currently ask isDeleted(), right?)


Andi Vajda wrote:

> 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

More information about the chandler-dev mailing list