mirror of
https://github.com/camptocamp/odoo-cloud-platform.git
synced 2026-06-24 08:47:40 +00:00
Guewen Baconnier
795692ad78
An Object Storage read is slower than a disk of database access. It might take ~200 to 300ms to retrieve a file content. This is not an issue for attachments such as the pdf files or any attachment that we want to read on demand. But that's too slow for files needed to render a web page. We'll store in the database: * Assets (js, css, ...). As a side effect, the databases will be more portable, as assets are rebuilt frequently, storing them in the Object Storage led the integration server to try to read assets deleted since long ago * Attachments linked to Binary fields named 'image_small', 'image_medium', 'web_icon_data'. Those fields are often used on kanban views that display a lot a images and retrieving them all was then very slow (Odoo does not do async requests). The migration to S3 is no longer called during initialization of the registry: it would be too slow as we would have to define if the attachments must be kept in database or sent to S3 on each new start. It means we have to call `env['ir.attachment'].force_storage()` to run the migration.
42 lines
1.3 KiB
ReStructuredText
42 lines
1.3 KiB
ReStructuredText
Attachments on S3 storage
|
|
=========================
|
|
|
|
This addon allows to store the attachments (documents and assets) on S3 or any
|
|
other S3-compatible Object Storage.
|
|
|
|
Configuration
|
|
-------------
|
|
|
|
Activate S3 storage:
|
|
|
|
* Create or set the system parameter with the key ``ir_attachment.location``
|
|
and the value in the form ``s3``.
|
|
|
|
Configure accesses with environment variables:
|
|
|
|
* ``AWS_HOST`` (not required if using AWS services)
|
|
* ``AWS_ACCESS_KEY_ID``
|
|
* ``AWS_SECRET_ACCESS_KEY``
|
|
* ``AWS_BUCKETNAME``
|
|
|
|
Read-only mode:
|
|
|
|
The bucket and the file key are stored in the attachment. So if you change the
|
|
``AWS_BUCKETNAME`` or the ``ir_attachment.location``, the existing attachments
|
|
will still be read on their former bucket. But as soon as they are written over
|
|
or new attachments are created, they will be created on the new bucket or on
|
|
the other location (db or filesystem). This is a convenient way to be able to
|
|
read the production attachments on a replication (since you have the
|
|
credentials) without any risk to alter the production data.
|
|
|
|
This addon must be added in the server wide addons with (``--load`` option):
|
|
|
|
``--load=web,web_kanban,attachment_s3``
|
|
|
|
Limitations
|
|
-----------
|
|
|
|
* You need to call ``env['ir.attachment'].force_storage()`` after
|
|
having changed the ``ir_attachment.location`` configuration in order to
|
|
migrate the existing attachments to S3.
|