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?)
...Bryan
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
