Django 1.9.0 complains about SubfieldBase being deprecated

Issue #46 resolved
Ryan Causey created an issue

It seems that the usage of SubfieldBase on line 25 in django-jsonfield/jsonfield/ causes a deprecation warning to be output by Django that says from_db_value() should be used instead.

Rooting around in the documentation I was able to find what looks like relevant information:

I'm new to Python and Django so I don't currently know how to resolve this, but if I figure it out before it's fixed I'll make a pull request.


-Ryan Causey

Comments (21)

  1. Matthew Schinckel repo owner

    For what it's worth: if you are using Postgres, you should move to django.contrib.postgres' JSONField.

    I'm not sure when I'll have time to fix this for other backends.

  2. Ryan Causey reporter

    Turns out that is the back end I am using. Thank you for the information and I will look into using that instead.

    All the best,

    -Ryan Causey

  3. Raphaël Hertzog

    Ping? The issue should be relatively easy to fix by adding a from_db_value() mimicking to_python() and by dropping the SubfieldBase inherit. We only care about compat with Django > 1.8 since all older versions are unsupported...

  4. Matthew Schinckel repo owner

    Indeed. However, I have little interest in writing a fix myself, since I have no use for this module under 1.9.

    Having said that, whilst I was a bit bummed initially about the deprecation of SubFieldBase, I'm sort-of coming around to the fact that it may not be the best way to do things (it is a bit magic about how it coerces a value on assignation).

    I will merge a pull request if one is created.

  5. Matthew Schinckel repo owner

    Okay, I have a passing test now. Sorry about that. I'd forgotten that merge broke stuff.

  6. Raphaël Hertzog

    So the change is easy but it breaks a lot of tests because now there's no longer any magic to convert a string containing JSON into the decoded objects when you assign the field value...

    Strictly speaking this is an API change... but I would say that the original behaviour was not consistent. It would treat string differently from lists and dicts... there was no way to store a plain string in a JSONField except by JSON-encoding it.

    Is this acceptable?

  7. Matthew Schinckel repo owner

    I'm not sure. I fear it may break stuff.

    I agree with the idea though. Maybe it could be a cause for a 2.0

  8. Raphaël Hertzog

    I created a pull request:

    Given your comment I opted to keep the old behaviour for old Django versions and to use the new behaviour only for Django versions > 1.8. I hope this is an acceptable tradeoff.

    I had to make a number of changes that I don't fully understand to get the (updated) test suite to pass (tried py27 and py35 with all Django versions but only with sqlite, not with PostgreSQL and MySQL) in particular in get_prep_lookup().

  9. Raphaël Hertzog

    Thanks, please make a new release if everything is fine (that way I can update the package in Debian).

  10. Matthew Schinckel repo owner

    There's still an issue I'm not 100% sure about (related to using default as a kwarg to dumps)

  11. Raphaël Hertzog

    Something discovered via codeship (I don't have access to its results) or something else just in your mind?

  12. Matthew Schinckel repo owner

    I'd like to, but I need to make the PR referenced above merge cleanly first. I don't currently have the time to do that right now (and in my projects, I'm using django.contrib.postgres JSONField instead of this one if they are 1.9)

  13. Log in to comment