View design document

The view is further detailed in FedoraViewBlobs. This document describes how the backend services should use to view to detect changes in records.

Changing an object and marking the view as updated

Whenever one of the components of a View is changed, the whole View count 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 Main object. The reverse is finding the Views, ie. the Main 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 basicly be one big list (VIEWS), that will associate each PID in DOMS with one or more PIDs of Main objects. In addition, there will be a list (MAIN_OBJECTS) of the Main objects, and whether they have changed since the list was generated. These lists will be made at one time, by computing the view of all main objects in Doms. All Main objects will have been found, and added to MAIN_OBJECTS. When appropriate changes are made to the objects in DOMS, the object in MAIN_OBJECTS will be marked as changed. Periodically, the View of changed main objects will be computed, and the VIEWS list will be updated, and the objects will be marked as not changed.

We expect to hook the fedora API-M functions directly, so that the updating of the VIEW lists are done without any user input.

There are several situations where the list will be used