Django 1.4: TypeError: get_db_prep_value() got an unexpected keyword argument 'connection'

[xthepoet]

This was working fine for my Ubuntu 10.04LTE system with Django
1.3.1. It seems broken now in 1.4.

In Django 1.4, I get this error TypeError: get_db_prep_value() got an
unexpected keyword argument 'connection' when saving an image to an
ImageField.

System (installed from Ubuntu Lucid repository packages):
Django 1.4
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)

The model field is defined as: origin_image =
models.ImageField(upload_to='images/origin')
The offending call is: obj.origin_image.save(fbFileName,
ContentFile(input_file.getvalue()))

Traceback (most recent call last):
File "/home/seeker/src/ceeq/seekerapp/management/commands/
addUser.py", line 100, in addPhotos
obj.origin_image.save(fbFileName,
ContentFile(input_file.getvalue()))
File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/
django/db/models/fields/files.py", line 95, in save
self.instance.save()
File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/
django/db/models/base.py", line 463, in save
self.save_base(using=using, force_insert=force_insert,
force_update=force_update)
File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/
django/db/models/base.py", line 551, in save_base
result = manager._insert([self], fields=fields,
return_id=update_pk, using=using, raw=raw)
File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/
django/db/models/manager.py", line 203, in _insert
return insert_query(self.model, objs, fields, **kwargs)
File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/
django/db/models/query.py", line 1576, in insert_query
return query.get_compiler(using=using).execute_sql(return_id)
File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/
django/db/models/sql/compiler.py", line 909, in execute_sql
for sql, params in self.as_sql():
File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/
django/db/models/sql/compiler.py", line 872, in as_sql
for obj in self.query.objs
File "/usr/local/lib/python2.6/dist-packages/Django-1.4-py2.6.egg/
django/db/models/fields/__init__.py", line 292, in get_db_prep_save
prepared=False)
TypeError: get_db_prep_value() got an unexpected keyword argument
'connection'

This problem was also reported on the django-celery board:
https://github.com/ask/celery/issues/624
But I've realized that for me, it's not a celery issue.

[Shawn Milochik]

On Sat, Apr 7, 2012 at 12:03 AM, xthepoet <sandr...@gmail.com> wrote:

This was working fine for my Ubuntu 10.04LTE system with Django
1.3.1.  It seems broken now in 1.4.

In Django 1.4, I get this error  TypeError: get_db_prep_value() got an
unexpected keyword argument 'connection' when saving an image to an
ImageField.

Field objects take 'connection' and 'prepared' kwargs in Django 1.4. It sounds like you're using a custom field which was written before those parameters existed, or perhaps you upgraded from a previous version and didn't delete all the .pyc files.

If it's the latter, it's a good idea to completely delete your Django directory from site-packages before re-installing. If it's the former, you can add the kwargs with a default of None and pass the values to the super() call.

 

[Russell Keith-Magee]

Hi,

What you've hit here is the end of the deprecation cycle for code that doesn't support multiple databases.

In Django 1.2, we introduced multiple database support; in order to support this, the prototype for get_db_preb_lookup() and get_db_prep_value() was changed.

For backwards compatibility, we added a shim that would transparently 'fix' these methods if they hadn't already been fixed by the developer.

In Django 1.2, the usage of these shims raised a PendingDeprecationWarning. In Django 1.3, they raised a DeprecationWarning.

Under Django 1.4, the shim code was been removed -- so any code that wasn't updated will now raise errors like the one you describe.

All the core Django fields should have been updated to use the new signature, so if you're seeing errors, it's probably because of a custom field that you're using that needs to be updated. As far as I can make out, Django's default ImageField shouldn't have this problem (it doesn't even have db_prep_* methods, because there's nothing database specific about the storage of FileFields).

If you can reproduce this on a project that only uses Django's built-in field types, then this is a bug in Django that needs to be addressed.

Yours
Russ Magee %-)

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com (mailto:django...@googlegroups.com).
> To unsubscribe from this group, send email to django-users...@googlegroups.com (mailto:django-users...@googlegroups.com).
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>

[shacker]

On Saturday, April 7, 2012 8:02:46 AM UTC-7, Shawn Milochik wrote:

Field objects take 'connection' and 'prepared' kwargs in Django 1.4. It sounds like you're using a custom field which was written before those parameters existed, or perhaps you upgraded from a previous version and didn't delete all the .pyc files.

If it's the latter, it's a good idea to completely delete your Django directory from site-packages before re-installing. If it's the former, you can add the kwargs with a default of None and pass the values to the super() call.

Russell's response is correct, but speaking of stale *.pyc files that may occasionally bite you, try putting this in your bash aliases:

alias delpyc='find . -name "*.pyc" -print0 | xargs -0 rm -rf'

Then you safely run "delpyc" from the top level of your project at any time to remove them all, ensuring that whatever problem you're experiencing isn't a result of them. 

./s

[Shawn Milochik]

On 04/08/2012 11:25 AM, shacker wrote:
>
> alias delpyc='find . -name "*.pyc" -print0 | xargs -0 rm -rf'
>
> Then you safely run "delpyc" from the top level of your project at any
> time to remove them all, ensuring that whatever problem you're
> experiencing isn't a result of them.
>

This is probably not true; you'll have to run your delpyc script on your
virtualenv (or Python site-packages) folder to ensure that the problem
you have isn't being caused by a zombie .pyc file in an installed
package. Running it in the project folder only deletes .pyc files you wrote.

Just a nitpicky point, but I wanted to point it out in case anyone else
followed this thread, deleted .pyc files in their project and wrongly
went on to a frustrating wild goose chase assuming they already ruled
out this problem.

Shawn

[Tom Evans]

On Sun, Apr 8, 2012 at 4:25 PM, shacker <sha...@birdhouse.org> wrote:
> Russell's response is correct, but speaking of stale *.pyc files that
> may occasionally bite you, try putting this in your bash aliases:
>
> alias delpyc='find . -name "*.pyc" -print0 | xargs -0 rm -rf'
>
> Then you safely run "delpyc" from the top level of your project at any time

Minor nit; .pyc files are, well, 'files', and so should not need
recursive or forced rm. Hence:

alias delpyc='find . -type f -name "*.pyc" -print0 | xargs -0 rm'

Cheers

Tom