-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/improve date selection #9160
base: main
Are you sure you want to change the base?
Changes from all commits
dfd3583
2d1592f
6d454a9
c665ec2
c6fc22b
9ef8335
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is inside a for loop, which might be called with 10k assets. Loading an asset from the database one at a time is going to be a problem. In hindsight, calling updateMetadata one at a time, which eventually calls upsertExif might not be the best either. I would probably recommend finding a more optimized solution. Ideally we move this logic into updateMetadata itself, and change that method to accept a list of ids to update. Only if the keepTimeUnchanged property is set, we can use the assetRepo.getByIds methods to load them in a single query.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also move the "keepTimeUnchanged" logic inside the SIDECAR_WRITE job or create a new one for that case.
The problem I see with changing multiple assets in one Job is the error handling.
What should happen if one of the metadata updates fail?
And maybe one side question:
is
await this.jobRepository.queue
waiting for the job to complete, or is it fire and forget. And what would happen if the SIDECAR_WRITE fails and theawait this.assetRepository.updateAll(ids, options); // asset.services.ts L 343
still is done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.queue is waiting for the job to be added to the queue. It is fine if the job takes longer to execute since it happens in the background.
Currently the bulk update (and single update) method optimistically update the database so the UI can refresh immediately and see the changes, but then persist the changes to a sidecar file so future metadata extraction doesn't erase/override the changes.
It is important that the initial implementation is fast, since the caller is waiting. Updating every asset individually makes that a little bit more difficult, especially if the asset needs to be read ahead of time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The options are to not do any update immediately, but defer it to the job. The user might be confused as the time isn't updated and the assets still appear in the wrong place for some time.
Or, update each asset one at a time, but optimize the loading to be in a single database request.