Aymeric, thanks for clarifying. I take your point for joins although I'm a bit surprised you don't feel JSONFields are appropriate for filtering.
I haven't tried yet but I am interested in the ability to efficiently index into the JSONField (thanks to use of Postgres' jsonb fields). That is, to design models that are a hybrid of our traditional, schema-oriented approach, but also include a JSON Field and offer the benefits of the more recent schemaless/nosql approach. Sorry if that's all a bit off topic for the django-dev list. Happy to switch over to django-users if that's more appropriate. Dwight -- Dwight Gunning Twitter me: @dwightgunning <https://www.twitter.com/dwightgunning> On 6 January 2016 at 15:27, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > 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> 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 > <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. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/upg9pgGvaUs/unsubscribe > . > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/django-developers/E507FE42-D738-410B-B447-D152A67797A3%40polytechnique.org?utm_medium=email&utm_source=footer> > . > > For more options, visit 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/CAJYoThPLk-XG8NfF9rafoDgA7_ML1P_xBtMFm38wYsnFsozaFA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.