[source] implement storages right in the source rather than in hooks The problem is that Storage objects will most probably change entity's dictionary so that values are correctly set before the source's corresponding method (e.g. entity_added()) is called. For instance, the BFSFileStorage will change the original binary data and replace it with the destination file path in order to store the file path in the database. This change must be local to the source in order not to impact other hooks or attribute access during the transaction, the whole idea being that the same application code should work exactly the same whether or not a BFSStorage is used or not.

i18n update

3.7.1

backport stable

[etwist] cleanup, use cProfile instead of hotshot

[repo] start looping task on repo only config (though I bet more work is needed to get it actually working

[repo] call server_startup event in start_looping_task the repo is fully started (registered in pyro for instance)

[security] take care uidrels may contains a relation targetting something else than a constant node (eg IN function)

[ms] this test is already done before putting a relation in uidrels

cleanup

[security] experimental rqlst cache for read security: to activate using a 'security-rqlst-cache' flag in transaction data when you'll issue a lot of identic queries with only kwargs varying

[read security] minor optimizations

[web] get rid of spurious '[Errno 2] No such file or directory' on load This was caused by can_do_pdf_conversion() which tries to use '/usr/bin/fop'. When fop was not available, an OSError was raised by suprocess.Popen. This changeset first checks for /usr/bin/fop presence, then tries to run fop. If an error occurs, log it instead of printing it. NOTE for later: why do we test explicitly for "/usr/bin/fop" rather than simply "fop" ?

backport stable