• Tasks
• 25
• DesignDocument

Design of Update Tracker Task

Design

The Update tracker will consist of a number of components.

1. A database, called DB. Estimated 2C. Probably request DB from IT Maintenance, otherwise we will use an embedded DB. This estimate is in sync with the estimate for the DB for IP2Roles
2. A JMS client. 2B, as Fedora comes with a messaging client out of the box. But 2, since it has been a while since we played with it last.

3. A JMS broker. 1C for DigiRes, as we expect to be able to request it from IT Maintenance, and only change config files. Their time expendure is not considered. See http://www.mail-archive.com/fedora-commons-users@lists.sourceforge.net/msg01144.html

4. The update tracker service. 1B. We always estimate the establising of services as 1B
5. The update tracker control flow. The control flow is detailed below. Estimate 6C. There is the task of translating design to code, and of speaking SQL or whatever to the database, and to solve concurrency problems.

The database will have two tables.

1. Entry Pid - Date changed - View Name - Date published or Deleted - State:
   • Associates each entry pid/view name combo with a changed date, and a date for the publication/deletion of the resource. State shows the current state: new, published, reworking (published, but taken back for further changes), deleted
2. Object Pid - Entry Pid - View Name:
   • Associates each pid in DOMS with a entry pid/view name combo.

There are two main flows in the service

1. Update:
   1. JMS client will be notified upon change to an object

   2. If the object change was create:

      1. if the object is not an entry object
         1. exit
      2. Add the correct line to table 1. State is set to new, or published (if the object is born active). Date changed is set. Published is set, if active.
      3. Add the selfreferential line to table 2.

   3. If the object change was delete

      1. Remove the object from table 2.
      2. If the object is the entry object from table 1: Change all entries for this entry object in table 1.state to deleted.
      3. exit

   4. If it was a normal change:

      1. The object pid is looked up in table 2 to a set of entry pid/view name combos. If none are found, nothing more needs to happen.
      2. Each of these combos gets the corresponding entry date changed updated in table 1.
      3. If the change was in RELS-EXT:
         1. For each view name for the entry object
            1. Request the view object list for this entry object, from ECM
            2. Delete all entries for entry pid in table 2.
            3. Add all objects from the ecm list to table 2.

      4. If the object change was publish

         1. Update the state for the entry object in table 1, and the date published
2. Lookup(date Since)
   1. Lookup in 1. to get object changed since date. (Summa search should only use date published, Summa gui should use date changed).
   2. If state is deleted, use the published date as the date of the deletion.

Secondly, there is the rebuild flow

1. Rebuild
   1. Drop the contents of table 1 and table 2
   2. From ECM, get all view angles
   3. For each view angle
      1. Get all entry pids for view angle
      2. for each entry pid
         1. Get the View object list for this object, from ECM
         2. Add the corresponding entries to table 2.
         3. Get the latest change-date from the view object list, and set this as the changed-date in table 1. If published, mark it as published on the last change date.

The update tracker should not return object blobs, only dates.

Prerequisites and Design Decisions

Required Software and Modules

Resources