#8307: ImageFile use of width_field and height_field is slow with remote storage
     Reporter:  sebastian.serrano@…  |                    Owner:  Jacob
         Type:                       |                   Status:  new
  Cleanup/optimization               |
    Component:  File                 |                  Version:  dev
  uploads/storage                    |
     Severity:  Normal               |               Resolution:
     Keywords:  imagefile height     |             Triage Stage:  Accepted
  width                              |
    Has patch:  1                    |      Needs documentation:  1
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
Comment (by Alan Justino da Silva):

 Replying to [comment:17 john-parton]:
 > I've got a fix that I think should pretty much always work.
 > ...
 > Basically, the FileField.save() method will call the descriptors __set__
 method with the value being a string.

 First, thanks for refreshing this 15yo issue, [comment:17 john-parton].

 That said, I do not see how this solution fixes a template page rendering
 ~10 images from a remote storage as there is no `.save()` involved for
 ''using existing images'':

 When I reopened the issue, my application needed only the URL of the
 files, already stored in the database, thus a O(1) call to DB. That is
 because I needed not to put height and width in the `<img />` HTML tag, as
 the browser deals with whatever it fetches from the URL. If grabbing the
 URL keeps forcing to `.get_image_dimentions()`, then this call becomes
 O(10) calls to the storage, meaning O(10) HTTP HEAD calls to S3. That is
 why I proposed ''the storage'' to decide if this should be done, or
 cached, or faked.

 Do you think that letting the storage proxy the image dimensions would be
 another way to fix your issues as well?
Ticket URL: <https://code.djangoproject.com/ticket/8307#comment:18>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to