289
edits
Calendar:Architecture: Difference between revisions
Jump to navigation
Jump to search
m
→Pros/Cons
m (→Pros/Cons) |
|||
| Line 151: | Line 151: | ||
Now for undo/redo: The previous approach can handle undo/redo easily because it keeps old items and jump back to a previous generation if requested. Since with the transaction system in place we don't provide copies of the items this approach is no longer possible. But undo/redo is essentially nothing more than a history log of changes, which fits into the transaction mechanism. | Now for undo/redo: The previous approach can handle undo/redo easily because it keeps old items and jump back to a previous generation if requested. Since with the transaction system in place we don't provide copies of the items this approach is no longer possible. But undo/redo is essentially nothing more than a history log of changes, which fits into the transaction mechanism. | ||
Upon <code>commit()</code>, the transaction system needs to store the last value of an attribute to be modified, before before committing the new one. That way, we could implement a rollback mechanism for items. Because each <code>commit()</code> transits the item from one consistent state into another, this won't violate data integrity. However, the number possible rollbacks needs to be configurable. xxx todo: where? | Upon <code>commit()</code>, the transaction system needs to store the last value of an attribute to be modified, before before committing the new one. That way, we could implement a rollback mechanism for items. Because each <code>commit()</code> transits the item from one consistent state into another, this won't violate data integrity. However, the number possible rollbacks needs to be configurable. xxx todo: where? '''jminta:''' probably use nsITransactionManager::maxTransactionCount | ||
== Comments are welcome == | == Comments are welcome == | ||