This document describes how the backend services should use to view to detect changes in records.
Given that we want to work on Views of data, we want to be able to monitor when an object View has changed. We say that an object View has changed if any of the objects in the View have changed.
States in Fedora get special treatment for a view. A View is considered Active if all objects are Active. A View is considered Deleted if the entry object is Deleted. In all other combinations the View is considered Inactive.
We want to be able to return all Views in a given Collection for a given State that have been modified after a given Time. To do this, we maintain a database of Views that is updated on all changes of an object.
Whenever one of the components of a View is changed, the whole View counts as updated. As such, any services that subscribe to the View in any way need to be notified. If there is a search index for the Views, and one is updated, its state in the index must be recomputed.
The problem arrives when trying to do this. The View system is designed to ease the computing of a View when knowing the Entry object. The reverse is finding the Views, ie. the Entry objects, that have this data object in their View. Rather than encoding this information in the model, we chose to keep an external record of all the views.
The external record will be SQL based, or something similar. It will have two tables.
The first table, ENTRIES, will have these columns
- entryPid: This is the pid of the entry object
- viewAngle: This is the viewangle
- state: This is the fedora object state
- dateForChange: This is the timestamp when this row was created
- collectionPid: This is the collection this entry object is part of
- contentModelPid: This is the content model that marked this object as an entry object in this view angle
EntryPid, viewAngle and State will form an unique key.
To explain the reasoning: Each Entry Object can be an entry object for multiple viewAngles. If the object state is changed, the old entry should remain. As such, each entry object can result in many rows.
The second table, OBJECTS, will have these columns
- objectPid: The pid of this object
- entryPid: The pid of the entry object that includes this object
- viewAngle: The name of the view angle by which the entry object includes this object
Finding Changed objects
To find changed objects we will ask for a set of objects with the following criteria
This can easily be found by a simple query in the ENTRIES table.
Changing an object and marking the view as updated
Basically, we need three kinds of operations to handle updates:
- We need to update the time for when a bundle was last updated. We'll call this "updateTimestamps"
- We need to update which bundles in which states exist. We'll call this "modifyState"
- We need to update which objects are part of the view. We'll call this "recalculateView"
There are a fixed number of operations that can be done on objects in doms.
For each of these, this is what should be done on the index as a result
Object Created: The Object was created in DOMS
Object Deleted: The Object was purged from DOMS
Object State Changed: The Object changed state in DOMS
Datastream Changed: The Object datastreams changed. Handled differently depending on whether this is the relations datastream
Object Relations Changed: The Object changed in a fashion that DOES require the view to be recomputed.
Each of these operations will be elaborated below
When the object state changes, we will have to update the state in the object, and possibly in any view containing the state.
So for each ENTRIES object containing this object, we update it with a new timestamp and state
- Active, if the new state is Active and all other objects in the view are current Active
- Deleted, if this is the entry object, and
- Inactive, otherwise
An object's relations changed. This could change which objects are in which entry's views.
We find all the Entries that contain this object by listing OBJECTS.
For each of these, we recalculate the view bundle and update the relevant rows in OBJECTS and ENTRIES.
Each row in OBJECTS specify that an object is contained in a named view for a specific entry object.
Then we update the ENTRIES table to mark that the view is changed.
This may also update content model or collection relations, which is handled separately