Differences between revisions 7 and 8

How to work without transactions

Fedora has no concept of transactions. There are situations where this is simply not good enough for the DOMS system. To get around this, we have built a system which gives us the most nessesary benefits of transactions.

Each data object in the DOMS is in one of three States.

draft - The object is still under preparation. The object can be edited freely. It is not available for public dissemination, and is disregarded by the validator.
published - The object is finished, and should be valid in regards to datamodel. The object is available for public dissemination.
intermediate - The object published, but is temporarily offline, as it is being updated. It is not available for public dissemination and will be disregarded by the validator.

The transition between these three states can be seen here

attachment:StateTransition.jpeg

Newly created objects will always be in the draft state. Once a user decide the object is ready for the public, the state should be changed to published. This will cause the validator to run, and if the object is valid, it will be published. Otherwise, the object will remain in draft, and the user will be notified about the errors.

Once the object is published, it can never revert to the draft state. If something needs to be changed, the object can be taken offline for a little while. The exact procedure is like this:

Load the object(s) locally, and perform the changes in your local version(s).
Change the state of the object(s) to intermediate
Write your changes to the object(s).
Change the state back to published. If your changes broke (any of) the object(s), the validator will report errors, and the state will not change (for these objects).

The State representation in an object

We have chosen to store the state as a rdf literal. This means Ressource Index queries about it are possible, which

The schema for the STATE datastream can be seen here

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance#"
            targetNamespace="http://doms.statsbiblioteket.dk/properties/state/0/1/#"
            xmlns="http://doms.statsbiblioteket.dk/properties/state/0/1/#"
            elementFormDefault="qualified"
            attributeFormDefault="unqualified">

    <xsd:element name="state" type="extpropertiesType"/>

    <xsd:complexType name="extpropertiesType">
        <xsd:attribute name="value" type="valuesType"/>
    </xsd:complexType>

    <xsd:simpleType name="valuesType">
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="published"/>
            <xsd:enumeration value="intermediate"/>
            <xsd:enumeration value="draft"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:schema>

It is defined in the datastream STATE_SCHEMA in ContentModel_DOMS.

The STATE datastream will therefore look like

<s:state value="published" xmlns:s="http://doms.statsbiblioteket.dk/properties/state/0/1/#"/>

<s:state value="intermediate" xmlns:s="http://doms.statsbiblioteket.dk/properties/state/0/1/#"/>

<s:state value="draft" xmlns:s="http://doms.statsbiblioteket.dk/properties/state/0/1/#"/>

-  ⇤ ← Revision 7 as of 2008-09-30 12:47:33 → 
  Size: 2951
  Editor: abr
  Comment:
+   ← Revision 8 as of 2008-10-15 16:07:28 → ⇥
  Size: 3347
  Editor: abr
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 4:
-Each data object must have a STATE datastream. This datastream has just one element, having one of three values.
+Each data object in the DOMS is in one of three States.
 Line 6:
- * published - The object is finished, and should be valid in regards to datamodel. The object can be harvested or indexed by other services
 * intermediate - The object is not ready for public dissemination. The validator will regard it as a valid object of any content models the object subscribes to, so relations to this object will be valid. The object will not be available for indexing or harvesting directly, but could be included in a bundle from another object.
 * draft - The object has just been made. Same as intermediate.
+ * draft - The object is still under preparation. The object can be edited freely. It is not available for public dissemination, and is disregarded by the validator.
 * published - The object is finished, and should be valid in regards to datamodel. The object is available for public dissemination. 
 * intermediate - The object published, but is temporarily offline, as it is being updated. It is not available for public dissemination and will be disregarded by the validator.
-Line 15:
+Line 16:
+Newly created objects will always be in the draft state. Once a user decide the object is ready for the public, the state should be changed to published. This will cause the validator to run, and if the object is valid, it will be published. Otherwise, the object will remain in draft, and the user will be notified about the errors.
-Line 16:
+Line 18:
-== Multiobject transactions ==

To emulate a transaction, follow these steps:
 1. Ingest any new objects, with STATE=draft
 1. change the STATE of all involved objects with STATE=published to STATE=intermediate
 1. Perform all changes that must be performed
 1. Change the objects back to STATE=published. This will provoke a validation of the objects by the DOMS system. If the objects failed the validation, the STATE will not change.
DOMS only try to enforce a structure on objects with STATE=published.
+Once the object is published, it can never revert to the draft state. If something needs to be changed, the object can be taken offline for a little while. The exact procedure is like this:
 1. Load the object(s) locally, and perform the changes in your local version(s). 
 1. Change the state of the object(s) to intermediate
 1. Write your changes to the object(s).
 1. Change the state back to published. If your changes broke (any of) the object(s), the validator will report errors, and the state will not change (for these objects).
-Line 26:
+Line 25:
-== The STATE datastream ==
+== The State representation in an object  ==

We have chosen to store the state as a rdf literal. This means Ressource Index queries about it are possible, which