1. 01 Nov, 2018 1 commit
  2. 07 Aug, 2018 1 commit
  3. 05 Jun, 2018 1 commit
    • Sean McGivern's avatar
      Fix an N+1 in avatar URLs · 2d392412bfdc
      Sean McGivern authored
      This is tricky: the query was being run in
      `ObjectStorage::Extension::RecordsUploads#retrieve_from_store!`, but we can't
      just add batch loading there, because the `#upload=` method there would use the
      result immediately, making the batch only have one item.
      Instead, we can pre-emptively add an item to the batch whenever an avatarable
      object is initialized, and then reuse that batch item in
      `#retrieve_from_store!`. However, this also has problems:
      1. There is a lot of logic in `Avatarable#retrieve_upload_from_batch`.
      2. Some of that logic constructs a 'fake' model for the batch key. This should
         be fine, because of ActiveRecord's override of `#==`, but it relies on that
         staying the same.
  4. 16 May, 2018 3 commits
    • Jan Provaznik's avatar
      Fixed typo · e0d8f7d4f26c
      Jan Provaznik authored
    • Jan Provaznik's avatar
      Use find_in_batches instead of destroy_all · 1b7d63ad6051
      Jan Provaznik authored
      destroy_all loads all records at once
    • Jan Provaznik's avatar
      Delete remote uploads · 9cb2812d4482
      Jan Provaznik authored
      ObjectStore uploader requires presence of associated `uploads` record
      when deleting the upload file (through the carrierwave's after_commit
      hook) because we keep info whether file is LOCAL or REMOTE in `upload`
      For this reason we can not destroy uploads as "dependent: :destroy" hook
      because these would be deleted too soon. Instead we rely on
      carrierwave's hook to destroy `uploads` in after_commit hook.
      But in before_destroy hook we still have to delete not-mounted uploads
      (which don't use carrierwave's destroy hook). This has to be done in
      before_Destroy instead of after_commit because `FileUpload` requires
      existence of model's object on destroy action.
      This is not ideal state of things, in a next step we should investigate
      how to unify model dependencies so we can use same workflow for all
      Related to #45425