Calendar Server includes the Delete Log database (ics50deletelog.db) to store deleted events and todos (tasks).
In early releases, Calendar Server did not maintain a database of deleted events and tasks. Users were forced to save the unique identifiers (uid) or recurrence identifiers (rid) of events or todos (tasks) to determine which components had been deleted. This limitation directly affected installations that used WCAP commands to develop a client user interface (UI). To solve this limitation, the delete log database was created.
This chapter describes:
Calendar Server automatically creates the Delete Log database (ics50deletelog.db) in the csdb directory along with the other Calendar Server database files. Calendar Server writes events and todos to the Delete Log database as follows:
Non-Recurring Events and Todos
When a non-recurring event or todo is deleted, Calendar Server removes it from the Events database (ics50events.db) or Todos database (ics50todos.db) and then writes it to the Delete Log database (ics50deletelog.db).
Recurring Events and Todos
When individual instances of a recurring event or task are deleted, Calendar Server writes each deleted instance of the event or task to the Delete Log database (ics50deletelog.db).
When all instances of a recurring event or todo are deleted, Calendar Server deletes the master component from the event or todo database and then writes it to the Delete Log database. A master component in the Delete Log database will contain the rrules, rdates, exrules, and exdates recurrence parameters.
To return entries from the Delete Log database, use the fetch_deletedcomponents WCAP command in either Expanded Mode or Compressed Mode:
Expanded Mode (recurring = 0)
If the recurring parameter is 0, fetch_deletedcomponents returns all instances of recurring events that match the criteria, but it does not return the master component for recurring events.
Compressed Mode (recurring = 1)
If the recurring parameter is 1, fetch_deletedcomponents returns non-recurring events and the master components for any recurring events, but it does not return individual recurring events.
If all instances in a recurring chain are deleted, the master component returns the dtstart, dtend, rrules, rdates, exrules, exdates, and uid parameters.
Also, fetch_deletedcomponents does not return master components associated with the deleted recurring instances that are still active. To return active master components, use the fetchcomponents_by_lasmod WCAP command. The fetch_deletedcomponents command should be used in conjunction with the fetchcomponents_by_lasmod command.
For more about WCAP commands, see the Sun Java System Calendar Server 6 2005Q4 Developer’s Guide.
Calendar Server provides both the Automatic Purge of the Delete Log Database and the Manual Purge of the Delete Log Database.
If you wish, you can have Calendar Server automatically purge entries in the Delete Log database.
The following table describes the parameters in the ics.conf file that control the automatic purge.
Table 18–1 Configuration Parameters for Automatic Purge of the Delete Log Database
Parameter |
Description |
---|---|
Enables ("yes") or disables ("no") the automatic purge of Delete Log database (ics50deletelog.db) entries. The default is "no". |
|
Specifies the interval time in seconds to automatically purge entries in the Delete Log database (ics50deletelog.db). The default is 60 seconds. |
|
Specifies a time in seconds before which to purge entries in the Delete Log database (ics50deletelog.db). The default is 86400 seconds (1 day). |
For example, to have Calendar Server automatically purge Delete Log database entries every five minutes (600 seconds) that are more than 2 days old (172800 seconds), set parameters in Automatic Purge of the Delete Log Database as follows:
service.admin.purge.deletelog="yes" caldb.berkeleydb.purge.deletelog.interval=600 caldb.berkeleydb.purge.deletelog.beforetime=172800
After you set these parameters, restart Calendar Server for the new values to take effect.
To manually purge entries in the Delete Log database (ics50deletelog.db), use the cspurge utility:
cspurge -e endtime -s starttime
where endtime and starttime specify the ending and starting times in Zulu time (also referred to as GMT or UTC).
To run cspurge, you must be logged in as the user and group under which Calendar Server is running (defaults are icsuser and icsgroup) or as root.
For example, to purge entries from July 1, 2003 through July 31, 2003:
cspurge -e 20030731T235959Z -s 20030701T120000Z
For more information, see cspurge.
The following table lists the Calendar Server utilities that support the delete log database (ics50deletelog.db):
Table 18–2 Utilities that Support the Delete Log Database
Utility |
Description |
---|---|
cspurge |
Allows the manual purge of entries in the Delete Log database. |
csbackup and csrestore |
Supports the backup and restore of the Delete Log database. |
csstats |
Reports Delete Log database statistics. |
csdb |
Supports the rebuild, recover, and check operations on the Delete Log database. |
cscomponents |
Lists (read-only) the number of entries in the Delete Log database. |
For more information, including the syntax for these utilities, see Appendix D, Calendar Server Command-Line Utilities Reference.