40 lines
1.4 KiB
Markdown
40 lines
1.4 KiB
Markdown
# POS Attribute Image Lazy Loading
|
|
|
|
Keeps `product.attribute.value` images out of the `pos.session.load_pos_data`
|
|
payload.
|
|
|
|
## The problem
|
|
|
|
`pos.session._get_attributes_by_ptal_id()` inlines the base64 `image` of every
|
|
attribute value of a `create_variant='no_variant'` attribute, **once per
|
|
attribute line** referencing it. With a handful of photo sized images this grows
|
|
without bound and the request dies while serialising the response:
|
|
|
|
```
|
|
File "werkzeug/wrappers/response.py", line 327, in set_data
|
|
value = value.encode(self.charset)
|
|
MemoryError
|
|
```
|
|
|
|
The browser only sees `ConnectionLostError` on
|
|
`/web/dataset/call_kw/pos.session/load_pos_data`, with no traceback in the POS.
|
|
|
|
Note that `product.attribute.value.image` is capped at 70x70 upstream, but
|
|
`product.template.attribute.value.image` is a related field declared without
|
|
`max_width`/`max_height`, so uploading through a product template's attribute
|
|
lines stores the original untouched.
|
|
|
|
## The fix
|
|
|
|
The POS front end never reads those bytes. `point_of_sale.ColorProductAttribute`
|
|
only tests the field for truthiness and renders the swatch from
|
|
`/web/image/product.template.attribute.value/<id>/image`. Reading under
|
|
`bin_size` returns the attachment size instead of its content, which is still
|
|
truthy, so nothing changes visually.
|
|
|
|
Measured on a production database with 224 images of ~1 MB:
|
|
|
|
| | `load_pos_data` payload |
|
|
|---|---|
|
|
| Without the module | 145.93 MB |
|
|
| With the module | 0.51 MB |
|