On Aug 6, 1:56 am, Mac <mmack3...@gmail.com> wrote:
> Hi,
>
> I'm new to django. When I try to upload image files, I get runtime
> errors. Here's my model:
> models.py
>
> class Images(models.Model):
> pk = models.IntegerField(primary_key=True, db_column='PK') # Field
> name made lowercase.
Unless you are going to be manually assigning values here -- and I
don't see any evidence of that in your code -- you probably want this
to be an AutoField, not an IntegerField. Based on the comments in
this model I'm guessing that it was auto-generated by inspectdb. Note
the results of inspectdb are meant to serve as a starting point for
your models, and in most cases will require some tweaking, such as
changing this generated IntegerField to an AutoField, assuming you
want this to be the automatically-assigned primary key field for the
model.
There's also another problem with this field but we'll get to that
later.
> photos = models.ImageField(db_column='PHOTOS', upload_to='img',
> blank=True) # Field name made lowercase.
> items = models.CharField(max_length=255, db_column='ITEMS',
> blank=True) # Field name made lowercase.
> date = models.DateField(null=True, db_column='DATE', blank=True) #
> Field name made lowercase.
> class Meta:
> db_table = u'IMAGES'
>
> Here's my view:
> rom django.core.files.uploadedfile import SimpleUploadedFile
> from PIL import Image
> Image.init()
> class PictureForm(forms.Form):
> pic=forms.ImageField()
> def create(self, file):
> mymodel = Images()
> mymodel.save_image_file(file.name, file, save=True)
> return mymodel
>
This looks very odd. If you want a form to allow you to upload an
image and save an Images model instances, why not use a ModelForm?
> def image_loads(request):
> form=PictureForm()
> if request.method=='POST':
> form=PictureForm(request.POST, request.FILES)
> if form.is_valid:
This line will always evaluate to True, regardless of whether or not
the form would pass validation. is_valid is a method, so you need to
call it:
if form.is_valid():
They way you have written it you are simply checking to see if the
form has the attribute is_valid, which it always will.
> form.create(request.FILES)
Note that request.FILES is a dictionary-like object. However your
create method above seems to be expecting an individual file. I think
you'd see a problem here if you ever got far enough for create to try
to access its file parameter.
>
> return render_to_response('photos.html', {'form':form, },
> context_instance = RequestContext(request))
>
> Here's my photos.html template:
>
[snip] because I don't notice any problem there.
>
> Any ideas why? I also tried creating a ModelForm using Images as the
> model, and I got the same runtime error. Here's the details:
>
Oh, you have tried a ModelForm. That is the right approach, go back
to it. The problem you are seeing is in no way related to using a
ModelForm and moving away from the right approach didn't get you any
closer to solving the real problem.
> Environment:
>
> Request Method: POST
> Request URL:http://localhost:8000/photos/
> Django Version: 1.1 beta 1 SVN-10891
> Python Version: 2.5.2
> Installed Applications:
> ['django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.contrib.admin',
> 'orders1.onhand',
> 'registration']
> Installed Middleware:
> ('django.middleware.common.CommonMiddleware',
> 'django.contrib.csrf.middleware.CsrfMiddleware',
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware')
>
> Traceback:
> File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py"
> in get_response
> 92. response = callback(request, *callback_args,
> **callback_kwargs)
> File "/home/malcolm/data1/orders1/../orders1/onhand/views.py" in
> image_loads
> 50. form.create(request.FILES)
> File "/home/malcolm/data1/orders1/../orders1/onhand/views.py" in
> create
> 41. mymodel = Images()
> File "/usr/lib/python2.5/site-packages/django/db/models/base.py" in
> __init__
Note how far you have gotten into your code. This problem has nothing
to do with uploading files: you are running into trouble simply trying
to create an Images instance. I suggest you take some time to do some
basic verification that things like your model definitions are working
before jumping into creating views and forms and templates, etc.
Playing around in the Python shell with your models, making sure you
can properly access existing ones and create new ones, is really
something that should be done before you start writing a lot of other
code. It is very worthwhile and makes everything go smoother if you
make sure that piece A works before building B,C, and D which all
depend on A.
> 313. setattr(self, field.attname, val)
> File "/usr/lib/python2.5/site-packages/django/db/models/base.py" in
> _set_pk_val
> 377. return setattr(self, self._meta.pk.attname, value)
> File "/usr/lib/python2.5/site-packages/django/db/models/base.py" in
> _set_pk_val
> 377. return setattr(self, self._meta.pk.attname, value)
> File "/usr/lib/python2.5/site-packages/django/db/models/base.py" in
> _set_pk_val
OK, we did not need to see 982 repetitions of line 377 in django/db/
models/base.py. Google doesn't think so either and makes it hard to
see the end of the message. You could have snipped at least 975 of
the copies and we would have gotten the idea that there's a problem
with infinite recursion here, ultimately reported as:
Exception Type: RuntimeError at /photos/
Exception Value: maximum recursion depth exceeded
by following the 'read more' link.
This looks like a Django bug or two. The problem is your primary key
field is named 'pk', which is the shortcut name that you can use to
refer to a primary key field without knowing its actual name. I don't
think it is feasible to allow a field to actually be named 'pk': if
you name a field 'pk' and it's not the primary key field, which field
should be returned when you try to access model.pk -- the field you
named 'pk' or the primary key field? So probably Django should report
this as an error on syncdb and make you change it. Also, inspectdb
ought not create a field with that name -- it already has logic to fix
up some other potentially problematic names so it should do the same
for 'pk', I expect.
The way to fix this in your code is to simply rename that field to
something else.
Karen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
