It's interesting that you say JSON Fields shouldn't be used for mission critical data. Is that widely recognised?
I feel like there are genuine uses cases for using JSON Fields to store mission critical data. For instance, a Javascript single-page-app style client with a set of user preferences to adjust the UI look and feel. These preferences need to be persisted between sessions but don't really need to be normalised or separated into individual fields by Django, aside from perhaps light validation. Datetime encoding/decoding to integrate with third party systems is a regular headache for me. I typically writ DRF serializers to take care of datetime formatting, but a more general solution closer to the data layer would be nice. Regards, Dwight -- On Tuesday, January 5, 2016 at 6:49:16 PM UTC+1, Aymeric Augustin wrote: > > > On 5 janv. 2016, at 18:37, Tom Christie <christ...@gmail.com > <javascript:>> 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/a2868ea8-c559-4240-aaba-dbf1f6efbe64%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
