| Interface to objects that control a change to the datastore.
All changes to the datastore must be done thru a datastore
change object.
There are a number of reasons why changes should be made
thru an IDatastoreChange object, and why plug-ins should not simply
call 'setter' methods, 'add' methods, and 'remove' methods.
-
If the underlying datastore supports transactions
(using 'transaction' with the meaning usually assumed
in the database community) then each IDatastoreChange object
will correspond to a single transaction in the datastore.
-
By using IDatastoreChange objects, multiple changes may be
consolidated into more efficient updates. For example,
if multiple property values are changed by calling the
setter methods then these can all result in a single
'update' statement being sent to the database.
-
IDatastoreChange objects manage locks. For example, consider a user
who opens two views that both allow the user to change the
properties of the same account.
Neither view will see changes from the other view until
those changes are committed. This can
cause confusion and cause changes to be lost, if the
user switched back and forth between the two views.
By using IDatastoreChange objects, the second view will not
be able to obtain an IDatastoreChange object and must act
appropriately (for example, by disabling the property
value fields).
-
'Undo' and 'Redo' support. The 'Undo'/'Redo' feature
keeps a list of the IDatastoreChange objects that performed changes
to the datastore. Every IDatastoreChange object must implement the
undo and redo methods.
|