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