6 The storage backend implements the "low level" folder abstraction, which is
7 basically an arbitary "BLOB" containing some document. The feature is that
8 we extract "quick access" / "searchable" attributes from the document content.
10 Further it contains the "folder management" API, as named folders can be stored
11 in different databases.
12 Note: we need a way to tell where "new" folders should be created
13 Note: to sync with LDAP we need to periodically delete or archive old folders
15 Folders have associated a type (like 'calendar') which defines the query
16 attributes and serialization format.
21 System-meta-data in the blob-table or in the quick-table?
22 - master data belongs into the blob table
23 - could be regular 'NSxxx' keys to differentiate meta data from
29 OCSContext - tracking context
30 OCSFolder - represents a single folder
31 OCSFolderManager - manages folders
32 OCSFolderType - the mapping info for a specific folder-type
33 OCSFieldInfo - mapping info for one 'quick field'
34 OCSChannelManager - maintains EOAdaptorChannel objects
38 - field 'value' (eg array values for participants?)
39 - BLOB archiver/unarchiver
44 OCSFolderInfoURL - the DB URL where the folder-info table is located
45 eg: http://OGo:OGo@localhost/test/folder_info
47 OCSFolderManagerDebugEnabled - enable folder-manager debug logs
49 [PGDebugEnabled] - enable PostgreSQL adaptor debugging
57 postgresql://[user]:[password]@[host]:[port]/[dbname]/[tablename]
64 - problem with iCal is that a complete and valid iCal file is different from
65 just the vevent. so we basically need to parse those files in any case.
66 - XML: the iCal SaxDriver reports XML events, so we can easily store that as
68 - we need to parse the BLOB for different clients anyway (iCal != iCal ...)
69 - XML: we could use some XML query extension to PG in the future?
75 - one to recreate a quick table based on the blob table
80 - need to use http:// URLs for connect info, until generic URLs in
81 libFoundation are fixed (the parses breaks on the login/password parts)
86 Q: Why do we use two tables, we could store the quick columns in the blob?
88 They could be in the same table. I considered using separate tables since the
89 quick table is likely to be recreated now and then if BLOB indexing
91 Actually one could even use different _quick tables which share a common BLOB
93 (a quick table is nothing more than a database index and like with DB indexes
94 multiple ones for different requirements can make sense).
96 Further it might improve caching behaviour for row based caches (the quick
97 table is going to be queried much more often) - not sure whether this is
98 relevant with PostgreSQL, probably not?
100 Q: Can we use a VARCHAR primary key?
102 I asked in the postgres IRC channel and apparently the performance penalty of
103 string primary keys isn't big.
104 We could also use an 'internal' int sequence in addition (might be useful for
106 Motivation: the 'iCalendar' ID is a string and usually looks like a GUID.
108 Q: Why using VARCHAR instead of TEXT in the BLOB?
110 To quote PostgreSQL documentation:
111 "There are no performance differences between these three types, apart from
112 the increased storage size when using the blank-padded type."
113 So varchar(xx) is just a large TEXT. Since we intend to store mostly small
114 snippets of data (tiny XML fragments), I considered VARCHAR the more