1 = Database Store = 2 3 The database data store offers a mechanism for storing calendar objects and free/busy 4 details in a database system, currently focusing on relational database systems, with 5 specific support for PostgreSQL. 6 7 Benefits of the database store include convenient and standardised interfaces for 8 querying and inspecting the data, together with various guarantees around the durability 9 of the stored data. However, more administrative knowledge is usually required to operate 10 database installations satisfactorily, and activities such as archiving require extra 11 planning and expertise. 12 13 The [[../FileStore|file store]] offers a more convenient method of managing calendar 14 data, albeit offering arguably less scalability and less convenience when data volumes 15 become significantly large. 16 17 == Configuration Settings == 18 19 The [[../Configuration|configuration]] files (`config.sh` and `config.txt`) need to be 20 updated when choosing a database store. 21 22 {{{#!table 23 '''File''' || '''Setting''' || '''Value''' || '''Description''' 24 == 25 `config.sh` 26 ||<rowspan="2"> `STORE_TYPE` 27 ||<rowspan="2"> `postgresql` 28 ||<rowspan="2"> Selects a specific database store type; currently, only `postgresql` 29 .. is supported 30 == 31 `config.txt` 32 == 33 <rowspan="2"> `config.txt` 34 || `STORE_DIR` 35 || `dbname=imip_agent` 36 || Indicates a connection string for the store database 37 == 38 `JOURNAL_DIR` 39 || `dbname=imip_agent` 40 || Indicates a connection string for the journal database 41 }}} 42 43 == Journal Structure == 44 45 The journal information is retained in a collection of tables. Unlike the structure of 46 the [[../FileStore|file store]] in the [[../FilesystemUsage|filesystem]], each table 47 contains details for all quota groups, with each query indicating the group to select 48 the appropriate information. 49 50 {{{#!table 51 '''Table''' || '''Purpose''' 52 == 53 `journal_freebusy_other` 54 || Period descriptions describing reservations for resources sharing a quota 55 .. (`store_user`) made by users or groups (`other`), structured similarly to the 56 .. `freebusy` table in the data store; this may be the same table as the one employed 57 .. by the data store to store received or deduced free/busy details 58 == 59 `journal_freebusy_providers` 60 || Details of [[../EventRecurrences|recurring events]] for which new free/busy records 61 .. must be [[../CronIntegration|periodically generated]] because these events recur 62 .. indefinitely, selectable for each user (`store_user`) 63 == 64 `journal_freebusy_provider_datetimes` 65 || Date/time details associated with the `freebusy_providers` information 66 == 67 `quota_delegates` 68 || Details of the identities (`store_user`) employing each quota (`quota`) to 69 .. consolidate their schedules, between which delegation may take place if their 70 .. schedules permit it 71 == 72 `quota_limits` 73 || A mapping from user identities or group identifiers to quota limits 74 == 75 `journal_objects` 76 || Records for each quota (`store_user`) containing received event data (`object_text`) 77 == 78 `journal_recurrences` 79 || Records for each quota (`store_user`) containing received recurrence event data 80 .. (`object_text`) 81 == 82 `user_groups` 83 || A mapping from user identities to group identifiers indicating the sharing of a quota 84 .. across a number of users 85 }}} 86 87 The `journal_` prefix is employed for certain tables in order to allow the combination of 88 the journal and store databases without each kind of data getting mixed up. 89 90 == Store Structure == 91 92 The store information is retained in a collection of tables. Unlike the structure of 93 the [[../FileStore|file store]] in the [[../FilesystemUsage|filesystem]], each table 94 contains details for all users, with each query indicating the user to select 95 the appropriate information. 96 97 {{{#!table 98 '''Table''' || '''Purpose''' 99 == 100 `countered_objects` 101 || Retains counter-proposals corresponding to events held in the `objects` table 102 .. received by each user (`store_user`) from another user (`other`) 103 == 104 `countered_recurrences` 105 || Retains counter-proposals corresponding to events held in the `recurrences` table 106 .. received by each user (`store_user`) from another user (`other`) 107 == 108 `freebusy` 109 || Period descriptions indicating start and end datetimes (in UTC), unique identifier 110 .. (`object_uid`), transparency, recurrence identifier (`object_recurrenceid`), 111 .. summary and organiser, reflecting the schedule of each user (`store_user`) 112 == 113 `freebusy_offers` 114 || Period descriptions for scheduling offers made by counter-proposals sent by each 115 .. user (`store_user`) 116 == 117 `freebusy_other` 118 || Period descriptions received or deduced for a user (`store_user`) structured 119 .. similarly to the user's own `freebusy` records 120 == 121 `freebusy_providers` 122 || Details of [[../EventRecurrences|recurring events]] for which new free/busy records 123 .. must be [[../CronIntegration|periodically generated]] because these events recur 124 .. indefinitely, selectable for each user (`store_user`) 125 == 126 `freebusy_provider_datetimes` 127 || Date/time details associated with the `freebusy_providers` information 128 == 129 `objects` 130 || Records for each user (`store_user`) containing received event data (`object_text`) 131 == 132 `requests` 133 || A collections of records, each belonging to a specific user (`store_user`) 134 .. consisting of a unique identifier (`object_uid`), normalised recurrence identifier 135 .. (`object_recurrenceid`) if appropriate, and (optionally) a scheduling method, 136 .. indicating the availability of an incoming scheduling request for handling by a user 137 == 138 `recurrences` 139 || Records for each user (`store_user`) containing received recurrence event data 140 .. (`object_text`) 141 }}}