Bug 1931622 - When using API to attach a file when too small for cloud storage, it will still try to get the new attachment from cloud storage generating an error #2362
Conversation
…d storage, it will still try to get the new attachment from cloud storage generating an error
There was a problem hiding this comment.
WFM.
Question: for the sake of consistency, could we just store all objects in cloud storage? What is the motivation for keeping blobs under 20kb in the database? For an object that small, I would be surprised if there is much of a performance win from a direct DB query compared to loading from cloud storage.
It's been 5 years so it is difficult to remember. We wanted to decrease the amount of external calls we would need to make for small attachments from what I recall. To help with performance for the majority of attachments. But yet keep the size of the DB as small as possible. The original bug is Bug 1588221 - Update current s3 storage controller to only upload attachments over a certain size. It would simplify things if we just sent everything to one place or the other. Let me create a bug to investigate the up and down sides. |
This change sets the $attachment->{data} value to the currently submitted attachment data. Later this will prevent having to hit the database or net storage for the data if the same object is being used elsewhere. If the object is gone and another one is instantiated, then the data will be loaded from the correct location. This also solves the error in the bug report because the same object is being used later to return results to the client.