So, I think a DEP is needed. I think we should start with the following for every database supported by Django (and the more common 3rd party ones):
If every major DB supports JSON out of the box, we may I mean we just forced everyone to go to Python3. We haven't hit an LTS since. Maybe bumping up a few DB versions is acceptable too? I actually did this research on Oracle, and it looks like the currently supported version of Oracle supports JSON and should out of the box with the supported version! *********** ORACLE Django supported minimum version (server/driver): Server:12.1; cx_Oracle: 5.2 Minimum version supporting JSON Field (server/driver): Server: 12.1 (maybe earlier); cx_Oracle: 5.2+ (I think so as it's just a special string field) Notes: Not a JSON specific field. Stored as VARCHAR2, CLOB, or BLOB. Suggest storing with is_json constraint to validate input is JSON that Oracle can parse. Reference: https://docs.oracle.com/database/121/ADXDB/json.htm *********** OTOH, MySQL looks like it'll need a version bump. *********** MySQL Django supported minimum version (server/driver): Server:5.5; mysqlclient; 1.3.7; MySQL Connector/Python: 1.1 Minimum version supporting JSON Field (server/driver): Server: 5.7.8; mysqlclient; ???; MySQL Connector/Python: ??? Notes: Implemented as a JSON field. Reference: https://dev.mysql.com/doc/refman/5.7/en/json.html *********** Quick research shows that PostgreSQL (at least from 9.3 the current minimum version), SQLite (via json1), MariaDB 10.0.1+, SQL Server 2016 (that's pretty new), Azure SQL Database ( https://docs.microsoft.com/en-us/sql/relational-databases/json/json-data-sql-server), DB2 (since z/OS V3.1 and Win/Linux/UNIX since 10.5) all support it. It appears that FirebirdSQL may not ( http://tracker.firebirdsql.org/browse/CORE-5148), and I don't think SQL Anywhere does either (based on quick googling). I don't think I missed any major relational DBs (though I'm sure people will comment with one I missed). There's always the idea that it could be a standard contrib module that has higher standards. I'm thinking something along the lines of GeoDjango here. Otherwise, I think one could just add a caveat that use of a JSON field requires a DB that supports JSON and fails if the version is too low or missing the extension (like json1 for sqlite). Then one should write a feature matrix to figure out what features are supported where. This can help drive the API. It also may point out that some relatively common feature doesn't appear until a newer version than just basic JSON support. With the general pervasiveness of JSON support, I'm not sure that one would need to write a full implementation based on a text field, though a couple features may require more hackery for certain DBs. Finally one has to take into consideration whether fields can be migrated on each Database and whether Django should help (maybe it shouldn't and force people to write migrations manually). On Thu, Mar 8, 2018 at 12:23 PM, Johannes Wilm <johannesw...@gmail.com> wrote: > Hey, > > is anyone working on this? Have this patchwork of solutions for different > databases systems in additionally the uncertainty associated with not > knowing which of the postgresql solutions will survive in the long run > really makes it a difficult decision to switch to anyone of these from a > plain TextField. Even if there is not there is no consensus to add it to > Django proper, could not at least the maintainers of the different > postgresql packages come up with a basic solution between themselves with a > simple fallback to TextField whenever one is using a different database? > > On Monday, June 27, 2016 at 12:29:30 PM UTC+2, Brad Jasper wrote: >> >> Current maintainer of https://github.com/bradjasper/django-jsonfield >> here and I would definitely support this. >> >> -Brad >> >> On Thu, Jun 23, 2016 at 9:28 AM, Aymeric Augustin < >> aymeric....@polytechnique.org> wrote: >> >>> Hello, >>> >>> On 23 Jun 2016, at 15:40, Tim Graham <timog...@gmail.com> wrote: >>> > Marc said, "I'm happy for JSONField to be made a core field on the >>> condition that it's underlying support is more than a text blob on all our >>> main databases. It sounds like this will soon be the case.” >>> >>> >>> In order to discourage people from using JSONField on databases where it >>> cannot be implemented efficiently i.e. not with a text blob, the best >>> solution may be to add it to Django and raise a warning when it’s misused. >>> >>> I’m not sure we can do that with a check, though, as we can’t introspect >>> database routing logic (without adding a disproportionate amount of >>> complexity). It would have to be a runtime warning. >>> >>> -- >>> 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/54f8d071-dc0c-47f6-b63e- > c9ec68288527%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/54f8d071-dc0c-47f6-b63e-c9ec68288527%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Joe Tennies tenn...@gmail.com -- 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/CACiOJ6vvKf2_WDBANLM1MVuuRV1RzgBUGMPupf4UWV5HePojvQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
