[19.0][IMP] fs_attachment: allow field keys in force db rules - #673
HviorForgeFlow wants to merge 1 commit into
Conversation
The force_db_for_default_attachment_rules only match on the mimetype
prefix. Some binary fields are read on every page load, like the menu
icons (ir.ui.menu.web_icon_data), and should be kept in the database
when the default storage is a slow object storage. With mimetype rules
only, the sole way to do it is to raise the "image/" limit, which keeps
all the images in the database.
A key without "/" but with a "." is now read as a "<model>.<field>"
pair, e.g. {"image/": 51200, "ir.ui.menu.web_icon_data": 0}. A field
rule is checked before the mimetype rules, with the same size limit
semantics, and is also applied in the domain used by
force_storage_to_db_for_special_fields to move existing attachments
back to the database. Existing mimetype keys always contain a "/", so
current configurations are not affected.
Assisted-by: Claude Opus 5.5
|
Hi @lmignon, |
lmignon
left a comment
lmignon
left a comment
There was a problem hiding this comment.
@HviorForgeFlow Thank you for the proposal. IMO you could achieve the same result by configuring a storage for these specific fields where you force the store into DB by default for all image mimetype.... no need for extra code. Do you have tested?
|
My use case, that's why I opened the PR is when, I have images lower than 50kb, the default configuration, placed in the DB when I want them place in s3, because they are related to products and other stuff. Then I was lookinjg for a quick way to store web_icon from icons and only needed attachments to run updates on Odoo "offline" without having access to the s3 storage. that's how I ended adding that feature to allow configure per model and field. Maybe another possibility could be adding the Odoo's postgres as new Protocol and configure using the model_ids and/or fields_ids. But maybe then we would need a priority on FS storage. |
|
Once a field is linked to a storage, that storage will always have priority when storing it, so there should be no need for a sequence. My concern with the current implementation is that it feels somewhat redundant with the possibility of linking a specific field to a storage. But I may be missing something, and the code is still quite readable. |
3 participants
The force_db_for_default_attachment_rules only match on the mimetype prefix. Some binary fields are read on every page load, like the menu icons (ir.ui.menu.web_icon_data), and should be kept in the database when the default storage is a slow object storage. With mimetype rules only, the sole way to do it is to raise the "image/" limit, which keeps all the images in the database.
A key without "/" but with a "." is now read as a "." pair, e.g. {"image/": 51200, "ir.ui.menu.web_icon_data": 0}. A field rule is checked before the mimetype rules, with the same size limit semantics, and is also applied in the domain used by force_storage_to_db_for_special_fields to move existing attachments back to the database. Existing mimetype keys always contain a "/", so current configurations are not affected.
Assisted-by: Claude Opus 5.5