ImageField, width_field, height_field not working

532 views
Skip to first unread message

Andrew Ingram

unread,
Jan 23, 2009, 6:55:22 AM1/23/09
to django...@googlegroups.com
Hi

I am trying to use the height_field and width_field arguments for
ImageField to auto-populate the dimension of images to other fields, but
it doesn't seem to be working.

I've duplicated the usage that's in Django's test suite (which
incidentally is the only mention I can find that you have to pass the
fields as strings rather than passing the fields themselves), and I've
produced the following model for testing this (after it didn't work on
my regular model).

class Test(models.Model):
image =
models.ImageField(upload_to='banners',height_field='image_height',width_field='image_width')

image_width = models.PositiveSmallIntegerField(editable=False)
image_height = models.PositiveSmallIntegerField(editable=False)

But when I try to upload the Image I get the following exception:

Exception Type: IntegrityError at /admin/banners/test/add/
Exception Value: (1048, "Column 'image_width' cannot be null")

If I allow the image_width and image_height fields to be Null, the image
itself gets uploaded fine but the dimension fields don't get populated.

I'm on Mac OSX 10.5 and I'm using the very latest revision of trunk. PIL
is installed and working.

Regards,
Andrew Ingram

Karen Tracey

unread,
Jan 23, 2009, 1:12:40 PM1/23/09
to django...@googlegroups.com

http://code.djangoproject.com/ticket/9545

also reports these fields not working, which I found a little mysterious since the function is tested in the test suite.  Your report provides a clue that the problem may be specifically with the admin (though the ticket doesn't mention admin), where (without actually looking at any code) I could guess the path taken to save the new model with an uploaded image somehow bypasses however these fields are normally set.  You might want to note in that ticket how you are encountering this problem in the admin.  The ticket also notes a custom save method can be used to get around the problem, which you may want to try if you want to get things working before the root cause of the problem is identified and fixed.

Karen

Andrew Ingram

unread,
Jan 23, 2009, 1:33:04 PM1/23/09
to django...@googlegroups.com
Thanks for your response Karen,

I've tried the workaround in the ticket and I get this error:

Exception Type: AttributeError
Exception Value: 'InMemoryUploadedFile' object has no attribute
'width'

I have a vague recollection that this was actually working before I did
the latest update on Django

Andrew Ingram

unread,
Jan 23, 2009, 1:40:09 PM1/23/09
to django...@googlegroups.com
I've just tried saving the model using the approach followed in Django's
unit test and the database gets populated correctly, this reinforces the
likelihood of it being an admin-related issue.

Regards,
Andrew Ingram,

Andrew Ingram

unread,
Jan 23, 2009, 6:19:55 PM1/23/09
to Django users
I reverted Django to revision 9756 (just after aggregation was merged
in) and everyone works fine, so evidently a commit made in the last
few days has caused this issue.

Regards,
Andrew Ingram

Malcolm Tredinnick

unread,
Jan 23, 2009, 9:11:16 PM1/23/09
to django...@googlegroups.com
On Fri, 2009-01-23 at 15:19 -0800, Andrew Ingram wrote:
> I reverted Django to revision 9756 (just after aggregation was merged
> in) and everyone works fine, so evidently a commit made in the last
> few days has caused this issue.

So the next thing is to narrow down which commit. You know a good commit
and you know a bad one. Now pick something halfway in between and try
that. Continue with binary searching. It won't take many repetitions to
get to the precise commit.

Regards,
Malcolm


Andrew Ingram

unread,
Jan 23, 2009, 9:21:52 PM1/23/09
to django...@googlegroups.com

Malcolm Tredinnick wrote:
> So the next thing is to narrow down which commit. You know a good commit
> and you know a bad one. Now pick something halfway in between and try
> that. Continue with binary searching. It won't take many repetitions to
> get to the precise commit.
>
> Regards,
> Malcolm
>
I've narrowed it down to revision 9766:

"Fixed #10044: You can now assign directly to file fields
(`instance.filefield = somefile`)."

http://code.djangoproject.com/ticket/10044

It's late now, but I'll update the ticket tommorrow if nobody else has
by then.

Regards,
Andrew Ingram

A Melé

unread,
Feb 3, 2009, 3:51:19 PM2/3/09
to Django users
It seems that after rev. 9766 ImageFieldFile's save() method (where it
sets values for height_field and width_field) is bypassed when saving
the file (at least with the admin). I use FieldFiles that inherit from
ImageFieldFile (for example in django-thumbs code (thanks for
reporting the issue, Andrew)) and I override the ImageFieldFile's save
() method with custom code. That code doesn't get executed when saving
the file with the admin when using rev.9766 and later revisions.

Regards,
Antonio Melé
http://django.es/

vicvicvic

unread,
Feb 4, 2009, 3:48:45 PM2/4/09
to Django users
Hello!

I have created a ticket for this issue, with a patch which solves it.
I don't think it breaks anything...

http://code.djangoproject.com/ticket/10196

alex....@gmail.com

unread,
Feb 4, 2009, 4:19:03 PM2/4/09
to Django users
That patch does indeed look to be correct, if you haven't already run
the test suite to ensure nothing breaks, and try to add an additional
test case to show that this solves the problem.
Reply all
Reply to author
Forward
0 new messages