Object metadata (Fix for scheduled backups retention)

Created on 5 September 2024, 2 months ago
Updated 7 September 2024, 2 months ago

Problem/Motivation

Cannot delete files per schedule id if metadata are not properly set.

Proposed resolution

Solution A: Leave the code as it is and, setting the backup and migrate schedule to keep al files use storage lifecycle rules to remove stale files.
Pro: Definitely more rules to play with than a number of jobs run.
Cons: user need access to the cloud management console
Solution B: Add the metadata directly in the protected function saveTheFile(BackupFileReadableInterface $file): ?StorageObject {
$object = NULL;
if (file_exists($file->realpath())) {
try {
$metadata = $file->getMetaAll();
$object = $this->getStorageBucket()->upload($file->openForRead(), [
'name' => $file->getFullName(),
'metadata' => [
'metadata' => $metadata,
],
]);
} catch...
Pro: saving an update operation compared to solution C
Cons: If there is a proper function why not use it (separation of concerns, reusability, testing, ...)
Solution C: Add the metadata with an update operation in saveTheFileMetadata function.
Pro: Opposite of solution B cons.
Cons: 1 update operation more than solution B.

I went for solution C.
Both solution B anc C required a major recoding of queryFiles function and a very needed change in listFiles function. While I was at it I added code also in loadFileMetadataArray function, you never know, it might come of use.
Note: If storage is configured for uniform-bucket access 🐛 Uniform bucket-level access Needs review is still needed, I kept that problem separate.

Remaining tasks

Add some testing?

🐛 Bug report
Status

Needs review

Version

5.0

Component

Code

Created by

🇮🇹Italy viappidu

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Production build 0.71.5 2024