Hello Dwight, I was trying to express the fact that JSONField is appropriate for storing data that won’t be used for joining other tables, filtering, aggregating, etc. but rather just for reading.
“Not mission-critical” was a simplification. That said, data that meets the criteria above tends not to be the most important data in an application. In your example, at worst, if your app fails to read what it wrote previously to the JSON field, the user will just have to set their preferences again. -- Aymeric. > On 6 janv. 2016, at 12:33, Dwight Gunning <dwi...@dwightgunning.com> wrote: > > 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 > > <http://gmail.com/>> 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 > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at https://groups.google.com/group/django-developers > <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 > > <https://groups.google.com/d/msgid/django-developers/a2868ea8-c559-4240-aaba-dbf1f6efbe64%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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/E507FE42-D738-410B-B447-D152A67797A3%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
