mirror of
https://github.com/camptocamp/odoo-cloud-platform.git
synced 2026-06-23 18:04:34 +00:00
Guewen Baconnier
e3e3899143
The initial issue that triggered this rework is that the forced storage in
database was working only on writes, and was never applied on attachment
creations.
This feature is used to store small files that need to be read in a fast way in
database rather than in the object storage. Reading a file from the object
storage can take 150-200ms, which is fine for downloading a PDF file or a single
image, but not if you need 40 thumbnails.
Down the path to make a correction, I found that:
* the logic to force storage was called in `_inverse_datas`, which is not called
during a create
* odoo implemented a new method `_get_datas_related_values`, which is a model
method that receive only the data and the mimetype, and return the attachment
values and write the file to the correct place
The `_get_datas_related_values` is where we want to plug this special storage,
as it is called for create and write, and already handle the values and
conditional write. But using this method, we have less information than before
about the attachment, so let's review the different criterias we had before:
* res_model: we were using it to always store attachments related to
'ir.ui.view' in db, because assets are related to this model. However, we
don't really need to check this: we should store any javascript and css
documents in database.
* exclude res_model: we could have an exclusion list, to tell that for instance,
for mail.message, we should never store any image in db. We don't have this
information anymore, but I think it was never used and added "in case of".
Because the default configuration is "mail.mail" and "mail.message" and I
couldn't find any attachment with such res_model in any of our biggest
databases. So this is removed.
* mimetype and data (size) are the last criteria and we still have them
The new system is only based on mimetype and data size and I think it's actually
more versatile. Previously, we could set a global size and include mimetypes,
but we couldn't say "I want to store all images below 50KB and all files of type
X below 10KB". Now, we have a single system parameter with a dict configuration
(`ir_attachment.storage.force.database`) defaulting to:
{"image/": 51200, "application/javascript": 0, "text/css": 0}
Assets have a limit of zero, which means they will all be stored in the database
whatever their size is.
Overall, this is a great simplification of the module too, as the method
`_get_datas_related_values` integrates it better in the base calls of IrAttachment.
Note for upgrade:
I doubt we customized the previous system parameters which are now obsolete, but
if yes, the configuration may need to be moved to `ir_attachment.storage.force.database`.
For the record, the params were:
* mimetypes.list.storedb (default: image)
* file.maxsize.storedb (default: 51200)
* excluded.models.storedb (mail.message,mail.mail), no equivalent now
The method IrAttachment.force_storage_to_db_for_special_fields() should be called
through a migration script on existing databases to move the attachments back into
the database.
61 lines
2.3 KiB
ReStructuredText
61 lines
2.3 KiB
ReStructuredText
Attachments on Swift storage
|
|
============================
|
|
|
|
This addon enable storing attachments (documents and assets) on OpenStack Object Storage (Swift)
|
|
|
|
Configuration
|
|
-------------
|
|
|
|
Activate Swift storage:
|
|
|
|
* Create or set the system parameter with the key ``ir_attachment.location`` with the following value ``swift``.
|
|
|
|
Configure accesses with environment variables:
|
|
|
|
* ``SWIFT_AUTH_URL`` : URL of the Swift server
|
|
* ``SWIFT_TENANT_NAME`` : **!** DEPRECATED **!** Use ``SWIFT_PROJECT_NAME`` instead
|
|
* ``SWIFT_PROJECT_NAME``
|
|
* ``SWIFT_ACCOUNT``
|
|
* ``SWIFT_PASSWORD``
|
|
* ``SWIFT_REGION_NAME`` : optional region
|
|
* ``SWIFT_WRITE_CONTAINER`` : Name of the container to use in the store (created if not existing)
|
|
|
|
Read-only mode:
|
|
|
|
The container name and the key are stored in the attachment. So if you change the
|
|
``SWIFT_WRITE_CONTAINER`` or the ``ir_attachment.location``, the existing attachments
|
|
will still be read on their former container. But as soon as they are written over
|
|
or new attachments are created, they will be created on the new container 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,attachment_swift``
|
|
|
|
The System Parameter ``ir_attachment.storage.force.database`` can be customized to
|
|
force storage of files in the database. See the documentation of the module
|
|
``base_attachment_object_storage``.
|
|
|
|
Python Dependencies
|
|
-------------------
|
|
|
|
This module needs the python-swiftclient and the python-keystoneclient (For auth v3.0) to work.
|
|
The python-keystoneclient needs the linux package build-essential and python-dev to install properly.
|
|
|
|
The python-swiftclient can be used from the command line, useful to test:
|
|
|
|
.. code-block:: sh
|
|
|
|
export AUTH_VERSION=3.0
|
|
export OS_USERNAME={SWIFT_ACCOUNT}
|
|
export OS_PASSWORD={SWIFT_PASSWORD}
|
|
export OS_PROJECT_NAME={SWIFT_PROJECT_NAME}
|
|
export OS_REGION_NAME={SWIFT_REGION_NAME}
|
|
export OS_AUTH_URL=https://auth.cloud.ovh.net/v3
|
|
swift stat
|
|
|
|
More information at
|
|
https://docs.openstack.org/python-swiftclient/latest/cli/index.html#swift-usage
|