Fedora Repository Views

...

But the angle one views the repository might also affect the number of entries seen. The above, recursive approach will always lead to one entry per data object. The remedy for this is to mark some classes as Entries for a certain view angle. This means that to compute the records for a given view angle, the view of all objects of a class that is an Entry should be computed. This is the view of the repository.

Fedora Implementation 

This section describes how the above could be implemented in Fedora. 

...

Each of these operations will be elaborated below

Object Created

...

Object State Changed

...

Object State Changed

...

...

When the object state changes, we will have to mark all ENTRIES containing this object in it's new state as changed, ie. with a new timestamp. If the object does not previously exist, this will do nothing, as it is not referred in the ENTRIES table.

If the object that changed is itself an Entry object, update/insert it into the ENTRIES. As each Entry Object will per definition include itself in it's view, also add to object to the OBJECTS table.

Code Block
language java
void objectStateModified(String pid, Date date, String state) {   //Find allthe EntriesDomsObject rows that includeregard this object. for (DomsObject result : results) { if (!result.getEntryPid().equals(pid)) { //Mark them as updated updateEntry(result.getEntryPid(), //There will be one per entry/viewAngle combination List<DomsObject> results = OBJECTS.list(objectPid=pid); //Find all Entries that include this object //If the object does not previously exist, this list will be empty for (DomsObject result : results) { if (!result.getEntryPid().equals(pid)) { //Mark them as updated state, updateEntry(result.getEntryPid(), result.getViewAngle(), state, date); result.getViewAngle(), date); } } // Find view Info for this object List<ViewInfo> viewInfoList = fedora.getViewInfo(pid, date); for (ViewInfo viewInfo : viewInfoList) { //If it is an entry object, set it in the ENTRIES table if (viewInfo.isEntry()) { updateEntry(pid, state, viewInfo.getViewAngle(), date); updateDomsObjects(pid, pid, viewInfo.getViewAngle()); } } } // Update the Entries table regarding a change void updateEntry(String entryPid, String state, String viewAngle, Date date) { //Find the Entry objects that fulfill these restrictions List<Entry> results = ENTRIES.list(entrypid,state,viewangle) //There might be no Entry, but if we are here, we know that an entry should exist, so create it. if (results.size() == 0) { ENTRIES.insert(new Entry(entryPid, viewAngle, state, date)); } else { for (Entry result : results) { //Is this entry older //Or there might have been some results   //Is this entry older than than the current change? if (result.getDateForChange().getTime() < date.getTime()) { result.setDateForChange(date); result.setEntryPid(entryPid); result.setState(state); result.setViewAngle(viewAngle); } //Save the entry ENTRIES.update(result); } } }   void updateDomsObjects(String objectPid, String entryPid, String viewAngle) { list<DomsObject> results = OBJECTS.list(objectPid,entryPid,viewAngle) if (results.size() == 0) { OBJECTS.insert(new DomsObject(objectPid, entryPid, viewAngle)); } }

 

Object Relations Changed

...

 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. 

void objectRelationsChanged(String pid, Date date) {

    //This can change the structure of the views and we must therefore recaculate the views

    //if a current entry object use this object, we will need to recalculate the view of that object

    //This method will only be called on objects that already exist. Objects cannot change type once created.
    //ObjectModified() creates an Entry row, if the object is an entry object. As such, there will always be
    // the correct Entry entries when this method is called, and these should just be recalculated

    List<DomsObject> results = OBJECTS.list(objectPid=pid);

    //we now have a list of all the entries that include this object.

    for (DomsObject result : results) {

        //get the ViewBundle from fedora
        ViewBundle bundle = fedora.calcViewBundle(result.getEntryPid(), result.getViewAngle(), date);

        //First, remove all the objects in this bundle from the table
        removeNotListedFromDomsObjects(bundle.getContained(), result.getEntryPid(), result.getViewAngle());

        //Add all the objects from the bundle to the objects Table.
        for (String objectPid : bundle.getContained()) {
            updateDomsObjects(objectPid, bundle.getEntry(), bundle.getViewAngle());
        }

        updateEntry(bundle.getEntry(), STATE_INPROGRESS, bundle.getViewAngle(), date);

    }
}


void removeNotListedFromDomsObjects(List<String> objectPid, String entryPid, String viewAngle) {

    List<DomsObject> results = OBJECTS.list(entryPid,viewAngle);

    for (DomsObject result : results) {
        if (!objectPid.contains(result.getObjectPid())) {
            OBJECTS.delete(result);
        }
    }
}

With these two functions, the rest of the events can be modelled as from them

Object Changed

This is the same as Object State Changed, if the state did not really change. If the state is not changed, this method will just update timestamps in 

The Object changed in some fashion that does not require the view to be recomputed, such as the content of datastreams.

Object Created

Object Deleted: The Object was purged from DOMS

Object Relations Changed: The Object changed in a fashion that DOES require the view to be recomputed.

There are several situations where the list will be used

...