I repost some of my blog posts made @ liip. Please see here for the original post and comments: https://blog.liip.ch/archive/2012/03/28/jackalope-observation-and-import-repository-dumps.html

Daniel Barsotti and me were reviewing the observation API of PHPCR and decided to just implement getting the observation journal. The journal contains all add, remove and update operations that happened on a PHPCR repository. You can also filter the journal by event type, path, node type and other criteria. This way, PHPCR can become almost a message queue (but just almost, there is no guaranteed delivery of messages).

use PHPCR\Observation\EventInterface; // Contains the constants for event types



// Get the observation manager

$workspace = $session->getWorkspace();

$observationManager = $workspace->getObservationManager();



// Get the unfiltered event journal and go through its content

$journal = $observationManager->getEventJournal();

$journal->skipTo(strtotime('-1 day'); // Skip all the events prior to yesterday

foreach ($journal as $event) {

    // Do something with $event (it's a Jackalope\Observation\Event instance)

    echo $event->getType() . ' - ' . $event->getPath()

}



// You can filter the event journal on several criteria.

// here we are only interested in events for node and properties added

$journal = $observationManager->getEventJournal(

    EventInterface::NODE_ADDED | EventInterface::PROPERTY_ADDED);



foreach ($journal as $event) {

    $event = $journal->current();

    // Do something with $event

    echo $event->getType() . ' - ' . $event->getPath()

}

The PHPCR / JCR standard also defines how to attach event listeners. The problem with this is that for any situation with concurrent repository access, the implementation needs to poll for events to trigger the listener. We assume that the JCR use case was a long running Java application that updates some local state based on polling events in a separate thread. For PHP, you neither have long running processes nor a thread system where you could do the polling. We decided that the journal will cover the most important use case: A cronjob that looks for specific events to act upon, instead of searching the whole repository each time and needing to determine if there is something changed that it needs to act upon.

Additionally, we implemented Session::importXML to import XML data into the repository. You can import both the JCR system view documents that are an exact dump of the repository and general XML documents where element names will be translated to PHPCR nodes and attributes to PHPCR properties.