Page History

...

RR introduces the general framework for an Event system

• JMO: how does this work with the submission workflow?
• RR: transactions work differently in this, because Events may violate transaction safety. Therefore, Events that are published are only cleared from the queue once the transaction has been released from the database
• RR: consumers can be either synchronous or asynchronous. Uses a JMS consumer, which places events in a persistent queue, which can then be run by some other process, or by cron at night. / JD: if a consumer raises an exception, does this stop the transaction? / RR: no. The transaction has completed.
• JMO: how does this work with the framework/modules planned / RR: great. It makes it possible to push services out of the content model, then it is just a case of writing the consumer
• MD: what's the content of the event?
• RJ: in an asynchronous environment the transaction termination ruins the context being passed in
• RR: History system will be a strong synchronous consumer, because of the need to be sure of the data chain
• RT: something like this is essential, especially for scalability
• JD: you need different mechanisms for interceptors and watchers
• JMO: if this looks good, we should make the recommendation, even if we leave further research as to how this is developed aside / JD: is what has already been developed by LS and RR ready to go into 1.5 / RT: there is no way currently of modelling what high-level events there are in the current code.
• JMO: doesn't have to be smart enough to work within the context, just needs to be smart enough to understand what has happened leading to the Event
• MD: Two models: single dispatcher that everyone subscribes to; all objects generating events, and listeners decide which they listen to. That is, single point of contact, or multiple points.

...

Two possible structures for storage are presented, as presented in the below diagram:

back to use cases

1) as before. see above

• Versions problem: revisions vs variants

...