Differences between revisions 1 and 11 (spanning 10 versions)
Revision 1 as of 2008-09-29 07:36:56
Size: 722
Editor: abr
Comment:
Revision 11 as of 2010-03-17 13:08:49
Size: 2761
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= 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.
Line 2: Line 4:
= Working with the Datamodel or How to work without transactions= Each data object in the DOMS is in one of three States.
Line 4: Line 6:
The STATE datastream, present in all data objects are the key. 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
Line 10: Line 7:
DOMS only try to enforce a structure on objects with STATE=published. By marking objects as intermediate, the system will disregard them, without losing the relations to them.  * 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:
 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).



== 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 is very desireable.

The ontology for all objects of [[DataModel/ContentModel DOMS| doms:ContentModel_DOMS]] require that all subscribing objects have a literal relation, called
"state:isInState". There is formal requirements that the object be in one of the three states, but the validator code will check this.

The "RELS-EXT" datastream will therefore have such a tag
{{{
<state:isInState xmlns:state="http://doms.statsbiblioteket.dk/properties/state/0/2/#"/>published</state:isInState>
}}}
or
{{{
<state:isInState xmlns:state="http://doms.statsbiblioteket.dk/properties/state/0/2/#"/>intermediate</state:isInState>
}}}
or
{{{
<state:isInState xmlns:state="http://doms.statsbiblioteket.dk/properties/state/0/2/#"/>draft</state:isInState>
}}}

== The Fedora API and State ==

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

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:

  1. Load the object(s) locally, and perform the changes in your local version(s).
  2. Change the state of the object(s) to intermediate
  3. Write your changes to the object(s).
  4. 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 is very desireable.

The ontology for all objects of doms:ContentModel_DOMS require that all subscribing objects have a literal relation, called "state:isInState". There is formal requirements that the object be in one of the three states, but the validator code will check this.

The "RELS-EXT" datastream will therefore have such a tag

<state:isInState xmlns:state="http://doms.statsbiblioteket.dk/properties/state/0/2/#"/>published</state:isInState>

or

<state:isInState xmlns:state="http://doms.statsbiblioteket.dk/properties/state/0/2/#"/>intermediate</state:isInState>

or

<state:isInState xmlns:state="http://doms.statsbiblioteket.dk/properties/state/0/2/#"/>draft</state:isInState>

The Fedora API and State

FedoraTransactionsReplacement (last edited 2010-03-17 13:08:49 by localhost)