Differences between revisions 5 and 6
Revision 5 as of 2008-10-30 10:53:40
Size: 3625
Editor: abr
Comment:
Revision 6 as of 2010-03-17 13:08:50
Size: 3625
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
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. 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.
Line 19: Line 19:
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 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.

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

  • Active: The object is published and available. The object has been validated against the content models that describes it.
  • Inactive: The object is not publicly available. It is not guaranteed to be valid in regards to the content models that describes it. It can still be edited in the GUI. All template objects are in this state, and all objects made from templates will begin life in this state.
  • Deleted: The object is deleted, and should not be available to anyone. It is in no way guaranteed to be valid. The GUI should not be able to work on it, it should not appear in GUI searches and so on. It is still in the repository, and special administration tools should be able to resurrect it.

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)