-
Interface Summary Interface Description History<P extends DataObject> HistoryFieldContributor HistoryHandler<P extends DataObject> LinkHistoryHandler<L extends Indexed,R extends Indexed,T extends IndexedLinkManager.Link<L,R>> -
Class Summary Class Description HistoryFactory<P extends DataObject,H extends HistoryFactory.HistoryRecord<P>> Class to generate History objects.HistoryFactory.HistoryRecord<P extends DataObject> Class Representing time history of and object.LinkHistoryAcceptFilter<L extends Indexed,R extends Indexed,T extends IndexedLinkManager.Link<L,R>,H extends History<T>> AcceptFilter selecting based on the Link peers.LinkHistoryManager<L extends Indexed,R extends Indexed,T extends IndexedLinkManager.Link<L,R>,H extends HistoryFactory.HistoryRecord<T>> History Factory for Link ObjectsLinkHistorySQLFilter<L extends Indexed,R extends Indexed,T extends IndexedLinkManager.Link<L,R>,H extends DataObject & History<T>,M extends DataObjectFactory<H> & LinkHistoryHandler<L,R,T>> SQLFilter for LinkHistory objects.PersonHistoryFactory<A extends AppUser>
Package uk.ac.ed.epcc.webapp.model.history Description
The HistoryFactory class is abstract and implements the general functionality.
Subclasses of HistoryFactory
track the state of particular model objects (the peer object).
A single record is used to store the entire period that a peer object remains unchanged so
that objects that change infrequently can be tracked efficiently. It is possible to add a history factory to a
DataObjectFactory so that the history is automatically updated when the comit method is called
or history can be tracked by making explicit calls to the update method on the HistoryFactory
Any database field in the peer object is automatically tracked if a field of the same name exists in the history table.
As History objects are only manipulated via the factory (they are logically part of a series rather than making sense on their own) then we make the History object an inner class of HistoryFactory. This allows us to avoid some duplication of methods
It is really difficult to make LinkHistory generic in any meaningful way, (its actually very difficult to get it to compile). We therfore do not use generic classes for History. This is very little loss as History typically works with the repository not the API of the class.
