Chapter 18 Administering the Delete Log Database

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:

• Creation of the Delete Log Database

• Querying the Delete Log Database

• Purging the Delete Log Database

• Using Calendar Server Utilities for the Delete Log Database

Creation of the Delete Log Database

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.

Querying the Delete Log Database

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.

Purging the Delete Log Database

Calendar Server provides both the Automatic Purge of the Delete Log Database and the Manual Purge of the Delete Log Database.

Automatic 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
service.admin.purge.deletelog	Enables ("yes") or disables ("no") the automatic purge of Delete Log database (ics50deletelog.db) entries. The default is "no".
caldb.berkeleydb.purge.deletelog.interval	Specifies the interval time in seconds to automatically purge entries in the Delete Log database (ics50deletelog.db). The default is 60 seconds.
caldb.berkeleydb.purge.deletelog.beforetime	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.

Manual Purge of the Delete Log Database

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.

Using Calendar Server Utilities for the Delete Log Database

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.