ottogroup / palladium / 608

90%

master: 90%

Pull #119

travis-ci

Proposal implementation for handling model attachments

The idea is that we sometimes want to attach files to models, such as
HTML reports or the like, and in the backend, these files should be
stored separately, to allow easy access.

Here we're implemeting this idea for the 'FileLike' model persister
and testing it for the 'File' subclass.  This should work for 'Rest'
and 'S3' as well, but I thought it's best to add tests when we all
agreed on the idea.

Usage is demonstrated in 'TestFileAttachments'.  The contract is as
follows: Use 'palladium.util.annotate' to add an arbitrary number of
attachments to the model, like so:

```
annotate(model1, {'attachments/myatt.txt': 'aGV5',
                  'attachments/my2ndatt.txt': 'aG8='})
```

Note that the keys of such attachments must start with 'attachments/',
with the rest indicating a filename.  The values must be base64
encoded but converted from bytes to strings.  This is arguably a bit
awkward, but we do this because the attachments dictionary must in
general be JSON serializable, and using bytes would violate this.

When 'model1' is persisted, 'FileLike' will create one file for each
attachment and call them 'model-1-myatt.txt' and
'model-1-my2ndatt.txt'.  The implementation chooses to use flat files
rather than a folder to hold all attachments for a given model.  This
is done so that we do not need to add extra methods to
'FileLikeIO' (such as mkdir), which means we should get support for
other 'FileLike' implementations such as 'Rest' and 'S3' for free.

Moreover, the attachments will be removed from the model's pickle and
from the metadata files, in order not to blow up the size of those.
When the model is loaded back through the model persister, the
attachments are loaded and put back into the model's metadata
dictionary.

What's a good time to add the attachments to the model?  Use the
'write_model_decorators' pluggable decorator hook to add a decorator
that adds your attachment just before i... (continued)

32 of 32 new or added lines in 1 file covered. (100.0%)

1279 of 1425 relevant lines covered (89.75%)

1.8 hits per line