Changeset 4185
- Timestamp:
- 27 May 2009, 09:33:29 (16 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
waeup/branches/ulif-rewrite/src/waeup/datacenter.txt
r4176 r4185 209 209 210 210 >>> os.unlink(filepath) 211 212 213 Data center helpers 214 =================== 215 216 Data centers provide several helper methods to make their usage more 217 convenient. 218 219 220 Receivers and receiver ids 221 -------------------------- 222 223 As 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 231 The latter normally is some kind of container, like a faculty 232 container or similar. This is what we call a ``receiver`` as it 233 receives the data from the file via the importer. 234 235 The datacenter finds receivers by looking up its parents for a 236 component, that implements `ICSVDataReceivers` and scanning that 237 component for attributes, that can be adapted to `ICSVImporter`. 238 239 I.e., once found an `ICSVDataReceiver` parent, the datacenter gets all 240 importers that can be applied to attributes of this component. For 241 each attribute there can be at most one importer. 242 243 When building the importer list for a certain file, we also check, 244 that the headers of the file comply with what the respective importers 245 expect. So, if a file contains broken headers, the file won't be 246 offered for import at all. 247 248 The contexts of the found importers then build our list of available 249 receivers. This means also, that for each receiver provided by the 250 datacenter, there is also an importer available. 251 252 If for a potential receiver no importer can be found, this receiver 253 will be skipped. 254 255 As one type of importer might be able to serve several receivers, we 256 also have to provide a unique id for each receiver. This is, where 257 ``receiver ids`` come into play. 258 259 Receiver 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 265 The value won this way is a long integer which we turn into a 266 string. If the value was get from the ZODB oid, we also prepend it 267 with a ``z`` to avoid any clash with non-ZODB objects (they might 268 deliver the same id, although this is *very* unlikely).
Note: See TracChangeset for help on using the changeset viewer.