> On 5 janv. 2016, at 18:37, Tom Christie <[email protected]> wrote: > >> Should JSONField accept additional kwargs to customize the encoder and the >> decoder? > > Quick take here: > > That sounds like a bit too much "cleverness" to me. The most obvious issue > it'd cause is putting values of one type into the field, but getting objects > of a different type back. (eg datetime getting coerced into a string on the > way in, and left as a string on the way out).
Yes, I understand how that could surprise a developer. A smart deserializer that would attempt to convert some strings back to their original type, based on their content, would create the opposite risk: a string that matches the format of a date could be accidentally returned as a date. I wouldn’t do this for mission-critical data — but then I wouldn’t store it in a JSON field either. Django projects should only use a JSON field for data that isn’t worth normalizing into actual fields. Writing a schema to map keys to types defeats the point; if you’re writing a schema, just express it with traditional model fields. I don’t think Django should (de)serialize non-native JSON types by default, but it should make it possible through public APIs, as this is a common requirement. For my use case, logging, the convenience of being able to store dates, datetimes and decimals without resorting the heavy guns (DRF serializers) helps a lot. -- Aymeric. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/B995F2B7-E1D1-4F82-8032-E502EA11680A%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
