Adds the possibility to insert `{db}` placeholder in the bucket name
that will be replaced by the database name to form a unique bucket
name per database.
With boto (odoo < 12.0) we use an hostname as AWS_HOST.
However with boto3, the connection must be initialized using an
URL containing a scheme (e.g https://)
This commit ensures we can use a simple hostname for odoo >= v12.0
without the need of specifying the scheme in the env var.
The previous error message let think that you should set AWS_BUCKETNAME,
although you should set it only if you are trying to write in this
repository.
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.
Because it provokes serialization errors during the installation or
update of addons. Do not commit as we might commit unwanted things...
Later, we might want to add a specific, more elaborate, migration
process.
* store the S3 uri in the 'store_fname' (s3://bucket/key)
* the read-only mode is now built-in, as we store the bucket name, if a
instance is started with a different bucket or another filestore
method, it will continue to read the previous attachments on their
stored bucket, but new attachments will be stored on the new one
* remove config in ir.config_parameter, it makes all the stuff more
complex and we don't use them (config file would be more interesting)
* automatically migrate the attachments on loading of the server, so
if an ir.attachment has been created during the module
upgrade/initialization before attachment_s3 is loaded, it will be sent
to S3 as soon as it's loaded
When we return a bin_size (such as 28672), the web client does not
accept it as as bin size and try to use it as value for the b64 src of
the image. Though, returning the image as b64 in all cases does seem to
be supported.
Yannick Payot
Miku LaitinenandYannick Vaucher
Patrick Tombez
Akim JuilleratandGuewen Baconnier
Tonow-c2c
jcoux