The docs and some tests contain references to a master/slave db configuration. While this terminology has been used for a long time, those terms may carry racially charged meanings to users. This patch replaces all occurrences of master and slave with 'leader' and 'follower'

Adds jQuery Select2 version 4 to support async select inputs including a search feature.

I split the PR in two commits, one is vendoring select2, one contains my code.

Links & Discussions

• djangoproject#14370
• https://groups.google.com/forum/#!topic/django-developers/tCNWnLP8jzM
• https://groups.google.com/forum/#!topic/django-developers/Ip63Xqw01IA/discussion
• https://groups.google.com/forum/#!topic/django-developers/jGgZngTq3Gw/discussion

Changes:

• ~~jQuery noConflict is set to false, jQuery itself does not get removed form global~~
• ~~the new select2 widget is automatically used if the related object has a registered admin and defines search fields~~
• only str representation is supported at this point
• the search feature uses the same field as the model admin

Todo:

• [x] ~~Possible deprecation of raw_id field?~~
• [x] Release note. (Which release?)
• [x] Selenium integration tests
• [x] widget tests
• [x] pagingnator and page tests
• [x] view tests
• [x] admin_site integration tests
• [x] add MODEL_change permission to json view
• [x] system checks

...aster/slave

All occurences of "master/slave" were recently replaced with "leader/follower" (https://github.com/django/django/pull/2692), then with "primary/replica" (https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a02352ae1). This new terminology is vague, ill-advised, and '''very misleading.'''

Django is a server-side framework with the goal of making Pythonistas' life sweet. By no means this requires reforming old and widely accepted database terminology, or feeding fat internet trolls like Feminist Software Foundation.

Let's look at the famous Zen of Python:

• Special cases aren't special enough to break the rules.
• Although practicality beats purity.
• There should be one-- and preferably only one --obvious way to do it.

And, above all:

• '''Explicit is better than implicit.'''

Here are four reasons, baked in the core of the language, as well as in the core or the developers' hearts, for why changing this '''old, clear, concise and immediately recognized''' terminology is a bad idea.

This terminology has been used for a long time, and by no means those purely technical terms carry racially charged meanings to users, neither are they offending in any other way. This patch replaces all occurrences of "primary/replica" with the good old "master/slave" together with now unnecessary comments like "referred to as master/slave by some databases".

Enforce a maximum size for form field values read into memory. Based on https://github.com/django/django/pull/3020 and https://github.com/django/django/pull/2403.

Hi,

This is just a rebase of https://github.com/django/django/pull/5297 The only difference (besides fixing the merge conflicts) is that ModelAdmin.declared_fieldsets doesn't exist anymore and was replaced by get_fieldsets.

Thanks,

Olivier

https://code.djangoproject.com/ticket/31034

I'm not altogether sure about my approach here. This seems to be the way that is the least disruptive to me, (almost) all the CSS is in a new file so it shouldn't affect users that have it turned off.

Really I think something like a drawer that slides from the side and covers some of the page would be better, as even with it only enabled on the largest breakpoint it can be a little crowded at the minimum size (1024px). Open to suggestions here. Also couldn't find a combination of heights and min-heights that would get the sidebar to cover the whole height of the screen without breaking something.

I decided to default to on since it seems like the majority of users would want that, and it's easy enough to turn off if upgrading and not wanting it.

Tested with latest Chrome, Firefox, Safari. Could use some eyes on other browsers.

Will add tests/docs after getting some feedback.

Screens:

15" Macbook:

At 1025px, the smallest size the sidebar will show up (a little crowded, but didn't want to add another breakpoint):

This pull request is closed. Please look at #12392 instead.

Ticket #12990, as part of the Google Summer of Code program.

Some points:

• Currently supports storing and retrieving any valid JSON value (boolean, integer, float, string, object, array) on all supported database backends (SQLite, PostgreSQL, MySQL, MariaDB, Oracle). Note: Oracle only supports JSON object and array if IS JSON constraint is enabled.
• Supports custom encoder and decoder (defaults to json.JSONEncoder and json.JSONDecoder, respectively). I had to cast the SELECT query to text for PostgreSQL to avoid having the value already decoded in from_db_value so it's possible to use a custom decoder (see psycopg2 docs).
• Custom lookups and transforms from contrib.postgres.fields.JSONField are implemented as possibly supported for each backend.
• Check constraints are applied.
  • MariaDB and SQLite have a JSON_VALID function which works well.
  • Oracle has IS JSON constraint, but from what I tried, it only returns true if the field's value is either a JSON object or array.
  • The constraint already comes with the JSON data types in PostgreSQL and MySQL. You can only insert valid JSON values for jsonb and json columns.
• Oracle implementation uses the nclob data type. Oracle recommends using blob, but there are some downsides (see docs). Besides, an existing implementation of oracle-json-field uses clob. TextField also uses nclob, so I think this makes sense.
• Needs JSON1 extension for SQLite. Most Linux distros already have it enabled by default in their SQLite and Python packages.
• Supports introspection.

More details of this available on my blog.

What did I do? I took https://github.com/dvarrazzo/django-psycopg3-backend and blackified it + ported over most (all?) new commits. I am now opening this on GitHub to be able to nicely diff and start a discussion about whether we can support psycopg2 & 3 easiyl from the same codebase (I think we can).

I (i.e. @felixxm) have the following plan to move this forward:

• [x] merge #16245,
• [x] squash commits,
• [x] rebase,
• [x] revert unnecessary changes, e.g.
  • [x] https://github.com/django/django/pull/15687#discussion_r1036784854
• [x] merge more small cleanups:
  • #16345
  • #16346
  • #16347
  • #16351
  • #16352
  • #16353
  • #16362
  • #16363
  • #16368
  • #16371
  • 2f38f7b8f9bd65905dc6bec4f3e2a30b5da8e338
  • 1d90c9b1132482d446ca8375c151e894002c9e8d
  • db7bb3b64e469fbb5c79e7b5b2fcb890434aa60f
• [x] push (or wait) for docs changes,
• [x] move import changes to a separate PR:
  • 2ebfbd894e21e1656c1e1f32d98b8df7a32d3649
• [x] make detailed review,
• [x] push (or wait) for final edits,
• [x] merge :tada:

Sort-of related to:

https://code.djangoproject.com/ticket/16603 https://code.djangoproject.com/ticket/25789

but this is dealing with .annotate(), rather than .filter() methods on a queryset.

https://code.djangoproject.com/ticket/27149

I'd love to have some review on this, but I'm fine with postponing the merge after Shai landed his changes to CSRF handling, as those two will get merge conflicts.

Ticket #29444

Currently the PK is hardcoded as the only retuning object which is not necessary and currently blocking #27452.

Side note:

This change should be fully backwards compatible. I am aware that this fix allows adding database defaults to all backends but MySQL. This is why I want to keep this an undocumented API for now. People will find out about it anyways.

You can implement a database default as follows:

class Default:
    """
    Expression for ``DEFAULT``.

    In an insert query this will return the database default.
    """

    def as_sql(self, compiler, connection):
        return connection.ops.pk_default_value(), []


class MyModel(models.Model):
    my_uuid_with_db_default = models.UUIDField(default=Default)

If you have a default set for your column in the database, it will return that instead of trying to set null. You no longer need to call refresh_from_db or any other strange thing.

This addresses the third item in #34041.

The last item in the breadcrumbs list now has an <a> tag with aria-current="page" attribute. This is a part of the accessibility changes suggested in the Breadcrumb ARIA authoring practices pattern.

Adds a manifest_hash attribute to ManifestFilesMixin exposing a "hash" of the full manifest. This allows applications to determine when their static files have changed.

Follow-up/clean-up of https://github.com/django/django/pull/16163 (ticket-34074)

With help from https://github.com/adamchainz/django-upgrade/pull/305, but also manually fixing. Ping @adamchainz to see the result the current state of the django-upgrade PR through the 3 commits.

We will squash all commits before merging, the 3 commits are for comprehension of the django-upgrade work :)

Fixed #34180 -- Wrote addition to docs to address a bug.

Added an explanation about a bug that changes the active language in subsequent tests when the test language is by using a cookie or HTTP header