public interface IAuditable extends IAuditableHandle, IManagedItem
Item handles and items are passive data objects that are retrieved or created while the client is logged in to a repository. These objects remain valid if the client logs out.
[TODO Issue: Deleting auditable items. Currently the client API does allow auditable items to be deleted. This keeps the sync story nice and simple, but it does mean that items will accumulate over time with no way of cleaning things up. Imagine how many contributor workspaces there would be in the Eclipse Platform team after 5 years of development. Kinda messy, to be sure. The big problem with actually deleting auditable items is that the audit trail would disappear too, which would be bad. This could be dealt with by dumping a journal of deleted item state elsewhere, just to satisfy the auditors. On the other hand, if we added a "marked as deleted - hide from end user" flag to auditable items, we could counter the clutter while keeping the story otherwise the same as it is now. MarkCC: I think the answer here is to distinguish between user operations and administrative operations; and administrative operations are not part of the client API. Removing an auditable from a *user* perspective doesn't actually delete it from the repository; it leaves it in the repository, but marks it as having no current state - just the log of previous states. In a separate administrators API, we should include a set of "pruning" operations, which can actually remove auditables and unneeded version sequences (i.e., version sequences from a workspace which was discarded, and which are no longer of interest.) jeem: It's not clear yet whether there will ever be any unsophisticated clients for the client API. I believe we can get away with telling clients that there are these "deleted" items which they should suppress when presenting to end users (and maybe providing them with an AccessProfile that suppresses deleted items from the results). This would be simpler than having a separate administrators API.]
[TODO Issue: Transactions for auditable items. Currently the client API does
not allow a client to create or modify multiple auditable items and then save
the new states in a single transaction. Consider adding a bulk
save(Collection
[TODO Issue: Locking for auditable items. Currently the client API does not allow a client to lock or reserve an auditable item that they are about to update. In situations where there may be a number of users vying to update the same item simultaneously, it may become difficult for users to get work done. The problem is magnified if there are large auditable item states where each user retrieves and updates just a small subpart, because the platform will have to treat these as conflicts even if there is an easy and automatic way to handle most of them. The schemas for the standard auditable items are all dead easy; it's likely that work items will push on this matter (cf. Bugzilla "Mid-air collision"). We should be on the lookout for signs that we will need to add locking sooner rather than later.]
[TODO Issue: Since save() only operates on a working copy, it cannot be used to replicate a state between repositories while preserving the state id. This means that we need to revisit the story of how the client prepares to go offline and how the resync when they come back online.]
| Modifier and Type | Field and Description |
|---|---|
static java.lang.String |
MERGE_PREDECESSOR_STATE_PROPERTY
The merge predecessor state property.
|
static java.lang.String |
PREDECESSOR_STATE_PROPERTY
The predecessor state property.
|
CONTEXT_ID_PROPERTY, ITEM_ID_PROPERTY, MAX_LARGE_STRING_BYTES, MAX_MEDIUM_STRING_BYTES, MAX_SMALL_STRING_BYTES, MODIFIED_BY_PROPERTY, MODIFIED_PROPERTY, STATE_ID_PROPERTY| Modifier and Type | Method and Description |
|---|---|
IAuditableHandle |
getMergePredecessorState()
Returns the secondary merge predecessor state of this auditable item
state.
|
IAuditableHandle |
getPredecessorState()
Returns the primary predecessor state of this auditable item state.
|
isNewItemgetContextId, getItemHandle, getModifiedBy, getRedactedCopy, getRequestedModified, getRequestedStateId, getStateHandle, getWorkingCopy, hasHistory, isComplete, isPropertySet, isRedactedCopy, isWorkingCopy, modified, setContextId, setRequestedModified, setRequestedStateIdequals, getAdapter, getFullState, getItemId, getItemType, getOrigin, getStateId, hasFullState, hasStateId, isAuditable, isConfigurationAware, isImmutable, isSimple, isUnmanaged, makeImmutable, protect, sameItemId, sameStateId, sizestatic final java.lang.String PREDECESSOR_STATE_PROPERTY
getPredecessorState()static final java.lang.String MERGE_PREDECESSOR_STATE_PROPERTY
getMergePredecessorState()()IAuditableHandle getPredecessorState()
IRepositoryItemService.fetchAllStates(IAuditableHandle) is
used to retrieve all the known states of the item, the predecessor (and
merge predecessor) states of each state can be used to construct the
version graph.
The initial state of an item has no predecessor state.
null if noneIAuditableHandle getMergePredecessorState()
IRepositoryItemService.fetchAllStates(IAuditableHandle)
is used to retrieve all the known states of the item, the predecessor
(and merge predecessor) states of each state can be used to construct the
version graph.
The initial state of an item has no predecessor state.
Design note: Without loss of generality, 0..2 predecessors is sufficient. Most states have exactly 1 predecessor. The initial state has 0 predecessors. And a state that comes about from a 3-way merge has 2 predecessors, tops.
null if none