Field class doesn't take connection and prepared arguments

[monokrome]

trafficstars

Fields in new versions of django can receive a connection and prepared argument. I believe this is for multi-db. Until django-ratings accepts these variables, django will throw a DeprecationWarning using djangoratings.fields.RatingField:

DeprecationWarning: A Field class whose get_db_prep_lookup method hasn't been updated to take `connection` and `prepared` arguments.

[neithere]

This warning appears at least in early snapshots of Django 1.3, not sure about 1.2.

[danawoodman]

Having same problem with SVN version of Django.

[feth]

I propose this : https://github.com/feth/django-ratings/commit/3c73f2b9e860f778bed348ed8748ccc1826285b5

But as I am fairly new to django, I'm not sure if it is sufficient (ie. does not cause another problem).

[neithere]

Django 1.3 prints two warnings (and feth's patch seems to address both):

[...]/djangoratings/fields.py:316: DeprecationWarning: A Field class whose get_db_prep_save method hasn't been updated to take a `connection` argument.
  class RatingField(IntegerField):
[...]/djangoratings/fields.py:316: DeprecationWarning: A Field class whose get_db_prep_lookup method hasn't been updated to take `connection` and `prepared` arguments.
  class RatingField(IntegerField):

It would be nice to see this fixed now that Django 1.3 is out.

[monokrome]

Personally, I would like to have someone that knows the internals of django's database code reassure that this fix is appropriate before committing to it. I'm pretty sure that it will cause backward compatibility issues with older Django versions.

[danawoodman]

I would assume running the regression tests Django comes with would give you your answer...

[john2x]

How about using @feth's fix, but passing a default value for the prepared and/or connection parameters to preserve backward compatibility? e.g.

def get_db_prep_save(self, value, connection=None):
def get_db_prep_lookup(self, lookup_type, value, connection=None, prepared=False):

[riggsd]

One method is a no-op, the second raises a NotImplementedError, nothing will break by fixing this issue; please implement @feth's trivial patch with @john2x's backwards compatibility note, or do it generically like this:

https://bitbucket.org/piquadrat/django-annoying/changeset/05460f0008ea

[andreslucena]

Kronuz's fork seems to have fixed this bug:

https://github.com/Kronuz/django-ratings/commit/aa8375e95279b493c734f2794bc65405cb96e5cb

[shacker]

Thanks andreaslucena - Yes, Kronuz's fork works.

[ashchristopher]

Has @dcramer addressed why this has not been pulled into master branch? Are there outstanding issues with this patch?

[churris43]

Any chances on getting this into the master branch? Thanks

[monokrome]

The person who forked this project and fixed this didn't send a pull request to @dcramer. Thanks to whomever it was that found the fork implementing a solution. I've mentioned it to @dcramer, so we'll see if he wants to merge it or if I should get the attention of @Kronuz on sending over a pull request.