Changeset 4185


Ignore:
Timestamp:
27 May 2009, 09:33:29 (16 years ago)
Author:
uli
Message:

Update docs.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • waeup/branches/ulif-rewrite/src/waeup/datacenter.txt

    r4176 r4185  
    209209
    210210    >>> os.unlink(filepath)
     211
     212
     213Data center helpers
     214===================
     215
     216Data centers provide several helper methods to make their usage more
     217convenient.
     218
     219
     220Receivers and receiver ids
     221--------------------------
     222
     223As already mentioned above, imports are defined as triples containing
     224
     225* a file to import,
     226
     227* an importer to do the import and
     228
     229* an object, which should be updated by the data file.
     230
     231The latter normally is some kind of container, like a faculty
     232container or similar. This is what we call a ``receiver`` as it
     233receives the data from the file via the importer.
     234
     235The datacenter finds receivers by looking up its parents for a
     236component, that implements `ICSVDataReceivers` and scanning that
     237component for attributes, that can be adapted to `ICSVImporter`.
     238
     239I.e., once found an `ICSVDataReceiver` parent, the datacenter gets all
     240importers that can be applied to attributes of this component. For
     241each attribute there can be at most one importer.
     242
     243When building the importer list for a certain file, we also check,
     244that the headers of the file comply with what the respective importers
     245expect. So, if a file contains broken headers, the file won't be
     246offered for import at all.
     247
     248The contexts of the found importers then build our list of available
     249receivers. This means also, that for each receiver provided by the
     250datacenter, there is also an importer available.
     251
     252If for a potential receiver no importer can be found, this receiver
     253will be skipped.
     254
     255As one type of importer might be able to serve several receivers, we
     256also have to provide a unique id for each receiver. This is, where
     257``receiver ids`` come into play.
     258
     259Receiver ids of objects are determined as
     260
     261* the ZODB oid of the object if the object is persistent
     262
     263* the result of id(obj) otherwise.
     264
     265The value won this way is a long integer which we turn into a
     266string. If the value was get from the ZODB oid, we also prepend it
     267with a ``z`` to avoid any clash with non-ZODB objects (they might
     268deliver the same id, although this is *very* unlikely).
Note: See TracChangeset for help on using the changeset viewer.