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

   1 # $Id$
   2
   3 Storage Backend
   4 ===============
   5
   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.
   9
  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
  14
  15 Folders have associated a type (like 'calendar') which defines the query
  16 attributes and serialization format.
  17
  18 Open Questions
  19 ==============
  20
  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
  24
  25 Class Hierarchy
  26 ===============
  27
  28   [NSObject]
  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
  35
  36   TBD:
  37   - field 'extractor'
  38   - field 'value' (eg array values for participants?)
  39   - BLOB archiver/unarchiver
  40
  41 Defaults
  42 ========
  43
  44   OCSFolderInfoURL - the DB URL where the folder-info table is located
  45     eg: http://OGo:OGo@localhost/test/folder_info
  46
  47   OCSFolderManagerDebugEnabled      - enable folder-manager debug logs
  48   OCSFolderManagerSQLDebugEnabled   - enable folder-manager SQL gen debug logs
  49
  50   OCSChannelManagerDebugEnabled     - enable channel debug pooling logs
  51   OCSChannelManagerPoolDebugEnabled - debug pool handle allocation
  52
  53   [PGDebugEnabled] - enable PostgreSQL adaptor debugging
  54
  55 URLs
  56 ====
  57
  58   "Database URLs"
  59
  60   We use the schema:
  61     postgresql://[user]:[password]@[host]:[port]/[dbname]/[tablename]
  62
  63 BLOB Formats
  64 ============
  65
  66 - TBD
  67 - iCal, XML
  68 - problem with iCal is that a complete and valid iCal file is different from
  69   just the vevent. so we basically need to parse those files in any case.
  70 - XML: the iCal SaxDriver reports XML events, so we can easily store that as
  71   XML
  72 - we need to parse the BLOB for different clients anyway (iCal != iCal ...)
  73 - XML: we could use some XML query extension to PG in the future?
  74
  75 Support Tools
  76 =============
  77
  78 - tools we need:
  79   - one to recreate a quick table based on the blob table
  80
  81 Notes
  82 =====
  83
  84 - need to use http:// URLs for connect info, until generic URLs in
  85   libFoundation are fixed (the parses breaks on the login/password parts)
  86
  87 QA
  88 ==
  89
  90 Q: Why do we use two tables, we could store the quick columns in the blob?
  91 ==
  92 They could be in the same table. I considered using separate tables since the
  93 quick table is likely to be recreated now and then if BLOB indexing
  94 requirements change.
  95 Actually one could even use different _quick tables which share a common BLOB
  96 table.
  97 (a quick table is nothing more than a database index and like with DB indexes
  98  multiple ones for different requirements can make sense).
  99
 100 Further it might improve caching behaviour for row based caches (the quick
 101 table is going to be queried much more often) - not sure whether this is
 102 relevant with PostgreSQL, probably not?
 103
 104 Q: Can we use a VARCHAR primary key?
 105 ==
 106 I asked in the postgres IRC channel and apparently the performance penalty of
 107 string primary keys isn't big.
 108 We could also use an 'internal' int sequence in addition (might be useful for
 109 supporting ZideLook)
 110 Motivation: the 'iCalendar' ID is a string and usually looks like a GUID.
 111
 112 Q: Why using VARCHAR instead of TEXT in the BLOB?
 113 ==
 114 To quote PostgreSQL documentation:
 115 "There are no performance differences between these three types, apart from
 116  the increased storage size when using the blank-padded type."
 117 So varchar(xx) is just a large TEXT. Since we intend to store mostly small
 118 snippets of data (tiny XML fragments), I considered VARCHAR the more
 119 appropriate type.