|
Size: 5092
Comment:
|
Size: 2610
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 27: | Line 27: |
| List<Records> getChangedSince(Date since, boolean published, String viewAngle) A record contain very little information Identifier State Date If published is set to true, the lookup will only concern itself with the published objects. |
|
| Line 30: | Line 38: |
| == Design == | |
| Line 32: | Line 39: |
| The Update tracker will consist of a number of components. 1. A database, called DB. 1. A JMS client 1. The update tracker service. 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 1. If the object change was '''create''': 1. if the object is not an entry object 1. exit 1. 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. 1. Add the selfreferential line to table 2. 1. If the object change was '''delete''' 1. Remove the object from table 2. 1. If the object is the entry object from table 1: Change all entries for this entry object in table 1.state to deleted. 1. exit 1. 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. 1. Each of these combos gets the corresponding entry date changed updated in table 1. 1. 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 1. Delete all entries for entry pid in table 2. 1. Add all objects from the ecm list to table 2. 1. If the object change was '''publish''' 1. Update the state for the entry object in table 1, and the date published 1. 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). 1. 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 1. From ECM, get all view angles 1. For each view angle 1. Get all entry pids for view angle 1. for each entry pid 1. Get the View object list for this object, from ECM 1. Add the corresponding entries to table 2. 1. 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. |
Task Update Tracker
- Title
- Task Update Tracker
- State
- Not started
- Time used
- Time estimated
Description
The goal of this task is to establish the Update Tracker mechanism in DOMS. The update tracker will provide the following functionality to DOMS
- Request Entry Pids changed since a given date.
List<Records> getChangedSince(Date since, boolean published, String viewAngle)
A record contain very little information
- Identifier State Date
If published is set to true, the lookup will only concern itself with the published objects.
Sub tasks
| Title | State | Time used | Time estimated |
Documentation
Progress history
| Iteration | Time used | Status | Notes | Tasks adressed |