Fedora State

All Fedora objects have a State property. This property can take one of three values, "Active", "Inactive" or "Deleted". While Fedora maintains this state for all objects, it attaches no meaning to it, and does not respect it in any way.

For DOMS, we need to work with the state of objects, so we have added meaning to the three states

The state of a object can be changed through the api Fedora 3.0 API/Management#modifyObject method. The DOMS system will hook this API method, so that whenever the state of an object change to Active, the validator will be invoked on the object. If the object cannot validate, the method will return an error, rather than changing the state.

All other Fedora API methods have been hooked, so that any attempts to change an object that is Active will return errors. First, use the above method to change the state to Inactive, then perform the changes, and then change the state back, so the validator checks the changed object. Any tools that attempt to disseminate the object while it is being edited will skip the object, as it is Inactive.

Best practice when working with views, is to set the whole view to "inactive" before changing anything in the view, then do all changes, and setting back state to "active".

Deleted

DOMS is a write-once storage. As such, purging any objects is not permitted. Instead, the state Deleted should be used. Changing the state is done through the API method Fedora 3.0 API/Management#modifyObject. Per Policy, you cannot delete an Object in the State Active. It must be set Inactive first. For the users, there are no way to undelete an object, as there should be no way to adress an object in Deleted state.

DOMS is a complex system, and deleting objects, without affecting the internal consistency is a difficult task. We have devised an policy for how this should be done.

When deleting an object, you must delete all the objects in this objects GUI view, but only if no object in the view is referenced from outside the view, except from a list of approved objects. Then purge the relations referencing objects in the view from all objects in the approved list. The approved list is supplied by the user; it contains the objects which are known to reference the objects to be deleted and deleting these references will be fine.

Given: Object d (to be deleted). Objectlist approved (the approved objects)

The formal algorithm to do this is:

  1. Find the view 'v' of object d.
  2. Find the list of objects 'e' that reference an object from 'v'
  3. Remove from the list 'e' all objects in approved, and all objects in 'v'
  4. If 'e' is not empty, the delete fails, and the user is notified about the contents of 'e'
  5. If 'e' is empty
    1. for all objects in approved, delete any relation they have to an object in 'v'
    2. mark all objects in 'v' as deleted

FedoraState (last edited 2010-03-17 13:08:50 by localhost)