Hi, Le vendredi 24 juin 2016, Shai Berger a écrit : > > Why would you want to discourage people? In the recent thread "Extending > > JSONField serialization", you said yourself that the use-case for a > > JSONField is clearly to store and retrieve data and not to make queries on > > it with smart lookups. > > So, what you're suggesting is actually a thin wrapper around TextField, which > deals with the JSON encoding?
That's the simplest answer that fullfills this requirement but I'm not suggesting that. I believe that a "core" JSONField should supersede all the existing implementations: - the external implementations which are close to your description (but got multiple related features over the years, not all of which are worth keeping) - the django.contrib.postgres one - the django-mysql one (that I wasn't aware of until Tim pointed out the older thread on this topic) So, in my view, it builds on the simplest implementation while relying on the native JSON database type when they are available and it should be easy to extend for the non-portable JSON-related features that each database might want to make available (special lookups, etc.). Even with a "thin wrapper", as soon as you rely on the native database types, you quickly get into non-trivial integrations problems: - with migrations from TextField to JSONField and vice-versa ex: https://bitbucket.org/schinckel/django-jsonfield/issues/54/migrating-from-textfield-to-jsonfield-with - with configuration requirements of the database connector that might have an impact on other parts of Django example where pyscopg does under the hood JSON conversion for us: https://bitbucket.org/schinckel/django-jsonfield/pull-requests/32/make-from_db_value-compatible-with On top of the model field, there would also be a FormField validating the JSON input and a widget to present the JSON in a human-readable (indented) form. Among the other features that would be interesting to have is the possibility to swap in a more advanced serializer (which would be able to deal with more types of objects than the default one). > I'm not sure the scope justifies a DEP, but some discussion of the API should > happen. Personally, I'm not yet convinced that -- assuming indeed we are > talking about a thinly-wrapped TextField -- such a field needs to have a > canonical implementation (one declared so by the Django project). Did my answer clear your doubts? Cheers, -- Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20160624114954.GB21727%40home.ouaza.com. For more options, visit https://groups.google.com/d/optout.