err.no Git - scalable-opengroupware.org/blob - OGoContentStore/README

   1 Storage Backend
   2 ===============
   3
   4 The storage backend implements the "low level" folder abstraction, which is
   5 basically an arbitary "BLOB" containing some document. The feature is that
   6 we extract "quick access" / "searchable" attributes from the document content.
   7
   8 Further it contains the "folder management" API, as named folders can be stored
   9 in different databases.
  10 Note: we need a way to tell where "new" folders should be created
  11 Note: to sync with LDAP we need to periodically delete or archive old folders
  12
  13 Folders have associated a type (like 'calendar') which defines the query
  14 attributes and serialization format.
  15
  16 TODO
  17 ====
  18 - hierarchies deeper than 4 (properly filter on path in OCS)
  19
  20 Open Questions
  21 ==============
  22
  23 System-meta-data in the blob-table or in the quick-table?
  24 - master data belongs into the blob table
  25 - could be regular 'NSxxx' keys to differentiate meta data from
  26
  27 Class Hierarchy
  28 ===============
  29
  30   [NSObject]
  31     OCSContext                  - tracking context
  32     OCSFolder                   - represents a single folder
  33     OCSFolderManager            - manages folders
  34     OCSFolderType               - the mapping info for a specific folder-type
  35     OCSFieldInfo                - mapping info for one 'quick field'
  36     OCSChannelManager           - maintains EOAdaptorChannel objects
  37
  38   TBD:
  39   - field 'extractor'
  40   - field 'value' (eg array values for participants?)
  41   - BLOB archiver/unarchiver
  42
  43 Defaults
  44 ========
  45
  46   OCSFolderInfoURL - the DB URL where the folder-info table is located
  47     eg: http://OGo:OGo@localhost/test/folder_info
  48
  49   OCSFolderManagerDebugEnabled      - enable folder-manager debug logs
  50   OCSFolderManagerSQLDebugEnabled   - enable folder-manager SQL gen debug logs
  51
  52   OCSChannelManagerDebugEnabled     - enable channel debug pooling logs
  53   OCSChannelManagerPoolDebugEnabled - debug pool handle allocation
  54
  55   OCSChannelExpireAge       - if that age in seconds is exceeded, a channel
  56                               will be removed from the pool
  57   OCSChannelCollectionTimer - time in seconds. each n-seconds the pool will be
  58                               checked for channels too old
  59
  60   [PGDebugEnabled] - enable PostgreSQL adaptor debugging
  61
  62 URLs
  63 ====
  64
  65   "Database URLs"
  66
  67   We use the schema:
  68     postgresql://[user]:[password]@[host]:[port]/[dbname]/[tablename]
  69
  70 BLOB Formats
  71 ============
  72
  73 - TBD
  74 - iCal, XML
  75 - problem with iCal is that a complete and valid iCal file is different from
  76   just the vevent. so we basically need to parse those files in any case.
  77 - XML: the iCal SaxDriver reports XML events, so we can easily store that as
  78   XML
  79 - we need to parse the BLOB for different clients anyway (iCal != iCal ...)
  80 - XML: we could use some XML query extension to PG in the future?
  81
  82 Update: we now have OCSiCalFieldExtractor
  83   - it parses the BLOB as an iCalendar file and extracts a set of fixed
  84     keys:
  85     - title        - plain copy of "summary"
  86     - uid          - plain copy
  87     - startdate    - date as utime
  88     - enddate      - date as utime
  89     - participants - CNs of attendees separated by comma ", "
  90     - location
  91     - partmails
  92     - sequence
  93     - TBD: iscyclic
  94     - TBD: isallday
  95     - TBD: cycles  - I guess the client should fetch the BLOB to resolve
  96   - the field extractor is accessed by OCSFolder using the folderinfo:
  97     extractor = [self->folderInfo quickExtractor];
  98     quickRow  = [extractor extractQuickFieldsFromContent:_content];
  99
 100 Support Tools
 101 =============
 102
 103 - tools we need:
 104   - one to recreate a quick table based on the blob table
 105
 106 Notes
 107 =====
 108
 109 - need to use http:// URLs for connect info, until generic URLs in
 110   libFoundation are fixed (the parses breaks on the login/password parts)
 111
 112 QA
 113 ==
 114
 115 Q: Why do we use two tables, we could store the quick columns in the blob?
 116 ==
 117 They could be in the same table. I considered using separate tables since the
 118 quick table is likely to be recreated now and then if BLOB indexing
 119 requirements change.
 120 Actually one could even use different _quick tables which share a common BLOB
 121 table.
 122 (a quick table is nothing more than a database index and like with DB indexes
 123  multiple ones for different requirements can make sense).
 124
 125 Further it might improve caching behaviour for row based caches (the quick
 126 table is going to be queried much more often) - not sure whether this is
 127 relevant with PostgreSQL, probably not?
 128
 129 Q: Can we use a VARCHAR primary key?
 130 ==
 131 I asked in the postgres IRC channel and apparently the performance penalty of
 132 string primary keys isn't big.
 133 We could also use an 'internal' int sequence in addition (might be useful for
 134 supporting ZideLook)
 135 Motivation: the 'iCalendar' ID is a string and usually looks like a GUID.
 136
 137 Q: Why using VARCHAR instead of TEXT in the BLOB?
 138 ==
 139 To quote PostgreSQL documentation:
 140 "There are no performance differences between these three types, apart from
 141  the increased storage size when using the blank-padded type."
 142 So varchar(xx) is just a large TEXT. Since we intend to store mostly small
 143 snippets of data (tiny XML fragments), I considered VARCHAR the more
 144 appropriate type.